Fazeo Software aide les PME, ETI et acteurs régulés à reprendre la main sur leurs applications vieillissantes : un état des lieux clair et chiffré d’abord, la modernisation ensuite, sans big-bang.
Prix fixes annoncés · Sans dépassement · Restitution en français clair
Le support d’une version de .NET s’arrête à une date publiée des années à l’avance. Passée cette date, plus aucun correctif de sécurité n’est publié pour elle.
Le développeur d’origine est parti, la documentation n’a jamais été écrite.
Personne ne peut dire ce que coûterait une modernisation, alors rien ne bouge.
Avec un état des lieux chiffré, on peut décider.
Voici un rapport d’audit flash : celui de Comptoir, une boutique en ligne en .NET Framework. Ouvrez-le axe par axe. Ce qui est mesuré, ce qui est jugé et ce qui est reconstitué n’y est jamais mélangé.
Pour la direction
Les huit axes
Après le diagnostic
Figée depuis plus de trois ans et demiannexe 7, Comptoir peut se moderniser par étapes, à condition de poser d’abord un filet de tests sur le tunnel de vente.
Les six premiers points chauds de l’application, ces fichiers à la fois complexes et souvent modifiés, portent tous sur la venteannexe 11. Rien ne lance les tests automatiquementannexe 12 : chaque modification du tunnel de vente se fait sans vérification systématique.
Le tri ramène 195 alertes brutesannexe 48 aux huit composants qui comptent. Un identifiant de service, retiré depuis, reste lisible dans l’historique du dépôtannexe 16.
Tout le code cible .NET Framework et ASP.NET MVC 5annexe 18, deux frameworks qui n’évoluent plus. Le serveur hôte, reconstitué, sort du support étendu dans moins de quatre mois.
Décision attendue. Engager le lot 1, la reprise en main du tunnel de vente, en novembre 2026. Chaque lot suivant se décide à la livraison du précédent.
Axe 1 sur 8
Couverture de la mesure : partielle. Un paquet sur 100 est absent de la base de versions : son retard n’est ni confirmé ni écarté. Les trois briques portées par le serveur hôte (système, serveur d’application, base de données) ne se lisent pas dans le code et restent à déclarer.
Tous les projets ciblent .NET Framework 4.7 avec ASP.NET MVC 5 et Web API 2annexe 18 : des frameworks qui n’évoluent plus. Aucune date de fin de support propre ne leur est attachée.
Sur 100 dépendances déclarées, 99 sont évaluées : 24 à jour, 4 en retard de correctif, 46 en retard mineur, 25 en retard d’au moins une version majeureannexe 45. 7 composants sont dépréciés par leur éditeurannexe 47.
Compte à rebours : Windows Server 2016 sort du support étendu le 12 janvier 2027.
Rien ne s’arrête demain. Mais chaque mois sans mise à jour rend la suivante plus chère : 25 composants à rattraper d’une version majeure ou plus, c’est autant de changements de comportement à absorber d’un coup.
À risque dès qu’une brique sort du support dans les 12 mois, critique si elle en est déjà sortie ou si l’échéance tombe dans les 3 mois. Ici l’échéance tombe 3 mois et 15 jours après la mesure, à peine au-delà du seuil critique : le niveau est à risque.
Faire confirmer le système hôte par l’exploitant, puis le migrer avant le 12 janvier 2027. Recibler .NET Framework 4.8 au lot 2. Rattraper les dépendances par ordre d’exposition, jamais en bloc.
L’exploitant pour le système hôte, avant le 12 janvier 2027. Lot 2 pour le framework et les dépendances.
Axe 2 sur 8
Couverture de la mesure : partielle. 54 % des éléments inventoriés n’ont aucun identifiant exploitable : ils échappent au rapprochement avec les bases de failles. Les composants web gérés par npm ne sont pas couverts.
L’outillage relève 195 alertes brutesannexe 48 : 11 critiques, 74 élevées, 107 moyennes, 3 faibles. Le tri les ramène à huit composants qui comptentannexe 52-59.
Cinq bibliothèques tierces portent une faille critiqueannexe 13, dont une dans l’outillage de construction, non livrée. L’une d’elles, celle des expressions dynamiques, est atteignable depuis le code de l’application.annexe 14
6 alertes figurent au catalogue des failles activement exploitéesannexe 50 : 4 sur des copies d’une bibliothèque JavaScript, de gravité moyenne, et 2 à confirmer.
Le risque réel est plus étroit que les 195 alertes, mais pas nul. Et la moitié du parc de composants, copiée à la main, échappe à toute veille.
À risque dès qu’une faille élevée touche un composant atteignable, critique dès qu’une faille critique atteignable est activement exploitée. Les alertes du catalogue d’exploitation ne sont pas critiques : le niveau s’arrête à « à risque ».
En gains rapides, les correctifs de même version majeure : expressions dynamiques, graphiques, journalisation. En priorité, qualifier l’exposition de l’API partenaires.
Gains rapides, puis l’API partenaires en priorité, hors lots. Le reste au lot 2.
Axe 3 sur 8
Couverture de la mesure : complète. Environ 240 fichiers de configuration ou de script et 3 500 fichiers source ont été contrôlés. Réserve : l’analyse des règles de code a rencontré 36 erreurs de compilation, ses constats sont à lire avec prudence.
Grille de 25 contrôles, 22 applicables, 13 déclenchésannexe 61.
Un identifiant de service, retiré depuis, reste lisible dans l’historique du dépôt.annexe 16 Les deux autres valeurs trouvées sont des valeurs d’exemple.
14 lignes signalées comme secret en clair : à la relecture, 12 faux positifs, aucune clé réelleannexe 64. Mode débogage laissé actif dans 14 configurationsannexe 31.
Un identifiant retiré du code reste lisible dans l’historique par quiconque a eu une copie du dépôt, prestataires passés compris.
À risque dès qu’un secret apparaît en clair dans l’historique, critique si un secret actif est en clair. Si l’exploitant confirme que cet identifiant est encore actif, le niveau passe à critique.
Faire vérifier et révoquer l’identifiant de service (gain rapide). Au lot 2 : qualifier le schéma de hachage des mots de passe, revoir désérialisations et certificats.
L’exploitant pour l’identifiant, en gain rapide. Le reste au lot 2.
Cet axe porte sur l’hygiène observable dans le code et la configuration. Il ne remplace ni un audit de sécurité ni un test d’intrusion.
Axe 4 sur 8
Couverture de la mesure : partielle. Les couches sont déduites des noms de projets : 60 % des projets n’ont pas de couche reconnue. Tant que les couches ne sont pas déclarées, aucun saut de couche ne peut être affirmé.
Une vingtaine de projets, 78 références entre eux, aucun cycle, aucune inversion de dépendance.annexe 9
4 modules d’extension sur une douzaine référencent directement le site au lieu du seul socle web communannexe 69.
16 points d’entrée. Adhérences au système d’information : web, SOAP, transactions, deux outils de bureauannexe 70.
Aucun cycle : l’application peut se moderniser par morceaux, en commençant par le noyau, à condition de confirmer d’abord ses couches. Les quatre modules branchés sur le site sont les premiers points à couper.
À risque dès qu’il existe des cycles entre couches ou une base partagée sans contrat, critique si aucune séparation n’est exploitable. Aucun cycle mesuré, mais la couverture est partielle : à surveiller, pas bon.
Déclarer les couches, puis couper les quatre références directes avant toute migration de la présentation.
Lot 3.
Axe 5 sur 8
Couverture de la mesure : complète. Analyse faite avec Roslyn, la plateforme de compilation de Microsoft. Réserve : avec 36 erreurs de compilation, complexité et maintenabilité sont approximatives, et plutôt flatteuses.
11 % des lignes utiles sont dans des fichiers à faible maintenabilité, sous le seuil d’alerte de 20 %annexe 72.
Les six premiers points chauds, des fichiers à la fois complexes et souvent modifiés, portent tous sur la vente : fiche produit, panier, commandes, prise de commandeannexe 11.
Dans le fichier de prise de commande, la méthode qui enregistre la commande a un indice de maintenabilité de 0 sur 100annexe 76.
Le code n’est difficile que par endroits, mais précisément là où passe l’argent. Personne ne peut prévoir l’effet d’une modification à cet endroit sans tests pour la vérifier.
À risque au-delà de 20 % du code en faible maintenabilité, critique dès que les points chauds concentrent le métier critique. Le seuil chiffré n’est pas franchi : 11 %. Le second critère l’est. Critique, par jugement, sur une criticité reconstituée.
Ne rien restructurer avant d’avoir figé par des tests le comportement actuel du tunnel de vente. Découper ensuite, fichier par fichier, sous ce filet.
Lot 1, puis chaque lot.
Axe 6 sur 8
Couverture de la mesure : complète. L’application a été reconstruite. Les tests existants ont été inventoriés, pas exécutés : c’est une limite de l’audit, écrite dans le rapport.
L’application se reconstruit hors production en moins d’une minute : une vingtaine de projets, 83 assemblages produits, sans erreurannexe 77.
Aucun pipeline d’intégration continue, 5 scripts de construction manuels.annexe 12
5 projets de tests, 160 fichiers de test, aucun exécuté automatiquement.annexe 43
L’essentiel est acquis : le code source correspond bien à une application qui compile. Mais les tests existants ne protègent rien tant que personne ne les lance.
À risque si la reconstruction hors production est possible mais non documentée, critique si elle est impossible. Le niveau est donné par la mesure et repris tel quel.
Écrire la construction dans un pipeline versionné, qui lancera les tests. Remettre en route les tests existants.
Gain rapide pour le pipeline, lot 1 pour les tests.
Axe 7 sur 8
Couverture de la mesure : complète. Réserve : les trois ans observés sont ceux qui précèdent le dernier commit, pas l’audit. Un dépôt figé est mesuré à la date où il s’est figé.
Sur les trois ans qui précèdent le dernier commit : environ 1 500 commits, 8 signatures actives au plus, la plus active en porte 30 %.annexe 80 La connaissance est répartie.
Plus aucun commit depuis début 2023annexe 10. Aucun document d’architecture dans le dépôt.annexe 83
Maintenance assurée par un prestataire externe, sans développeur interne.
La connaissance était répartie au moment où le code a cessé d’évoluer. Plus de trois ans et demi plus tard, elle vit hors de l’entreprise et vieillit. Un changement de prestataire se ferait aujourd’hui sans documentation pour prendre le relais.
À risque dès qu’un module critique n’a qu’un sachant, critique s’il n’y a plus aucun sachant dans l’entreprise. Aucun seuil n’est franchi. À surveiller plutôt que bon, parce que la mesure date du gel du dépôt.
Chaque lot livre sa documentation à jour. Le lot 1 pose la documentation d’architecture et le guide de reprise du tunnel de vente. Le plan est écrit pour être exécutable par n’importe quel prestataire.
Chaque lot, dès le lot 1.
Axe 8 sur 8
Couverture de la mesure : absente, à dessein. Aucun outil ne produit le verdict : l’auditeur l’écrit à partir des sept axes.
Ne tient pas : le socle n’évolue plus et les failles publiées restent ouvertes.
Suffirait si le socle était moderne. Il ne l’est pas.
Jetterait 270 000 lignes de métier qui se reconstruisent.
Retenu. Sans cycle entre projets et avec une application qui se recompile, la modernisation par étapes est la voie la moins chère et la moins risquée.
Effort. Trois lots pour sécuriser et préparer, puis la migration de la présentation.
La trajectoire peut s’arrêter après chaque lot. Prix, calendrier et découpage de ce rapport sont reconstitués : l’estimation de l’audit éclaire, le prix fixe qui engage est celui du devis.
Reprise en main du tunnel de vente. Tests automatisés sur la prise de commande, le panier et la fiche produit, qui figent le comportement actuel. Remise en route des tests existants, documentation d’architecture et guide de reprise.
Composants et hygiène de sécurité. Sortie des composants vulnérables et dépréciés par ordre d’exposition, binaires et scripts copiés remplacés par des paquets gérés, schéma de hachage qualifié, reciblage .NET Framework 4.8.
Préparation de la migration. Couches déclarées et confirmées, noyau passé au format de projet moderne et compilé pour les deux mondes. Les quatre modules branchés sur le site en sont détachés. L’application continue de tourner telle quelle.
Migration de la présentation vers ASP.NET Core. Environ 680 vues et 170 contrôleurs, chaque lot chiffré à prix fixe sur ce que le lot 3 aura révélé.
D’où vient ce rapport. C’est l’audit réel d’une application .NET open source, anonymisée : nom et modules remplacés, volumes arrondis. Aucun entretien n’a eu lieu, donc le client, l’hébergement, la criticité et le chiffrage sont reconstitués et marqués comme tels. Les petits numéros renvoient aux fichiers de mesure en annexe ; un chiffre reconstitué n’en a pas.
Une même échelle pour tout le rapport. Bon, à surveiller, à risque, critique. Les seuils de passage d’un niveau à l’autre sont fixés d’avance, axe par axe : deux audits se comparent ligne à ligne. Le rapport met en cause la dette technique, jamais les personnes.
Votre parc passé au crible : risques, qualité du code, effort de reprise, et un plan de modernisation priorisé avec des ordres de grandeur budgétaires par lot. Restitution d’une heure à la direction, rapport à l’appui. De quoi arbitrer.
Flash
1 application
2 950 €HT
Parc
jusqu’à 5 applications
Prix fixe, chiffré au cadrageDevis ferme sous 48 h
Pour l’application que tout le monde a peur de toucher : remise sous tests des règles métier sensibles et rétro-documentation, sans rien réécrire. Vos équipes peuvent la reprendre.
Module critique
tests + documentation
3 250 €HT
Application complète
tests + documentation
6 500 €HT
La mise en œuvre du plan, découpée en lots courts avec un livrable net à chaque fois : migration vers un .NET supporté, sécurisation des accès, sortie d’une dépendance bloquante.
Un lot
périmètres de 2 à 4 semaines
6 500 à 13 000 €HT par lot, chiffré par l’audit
En visio. Vous décrivez votre parc ; je réponds par un format, un prix et une date de démarrage possible. Vous recevez un devis précis sous 48 h.
L’audit et la reprise en main ne déploient rien : ils lisent votre code et produisent des documents. La modernisation, elle, met du code en production, à des dates que vous fixez.
Le rapport et le plan vous appartiennent. Le contrat s’arrête là : les lots de modernisation font l’objet d’une commande séparée, chez moi ou chez le prestataire de votre choix.
Pour les environnements les plus sensibles, un mode d’intervention entièrement hors ligne, outillage compris, est proposé sur demande.
L’audit ne touche pas au code : il lit, il chiffre, il produit un rapport. Votre prestataire garde la main. Je vends aussi les lots de modernisation : l’audit est à prix fixe et facturé à la remise du rapport, que sa conclusion soit « refondez » ou « ne touchez à rien ». Et si vous voulez écarter le conflit d’intérêts, demandez-le au cadrage : je m’engage par écrit à ne pas répondre à la consultation sur les lots qui suivent.
Parce qu’un prix fixe déplace le risque de dépassement sur moi : si l’audit prend deux jours de plus que prévu, vous payez le montant annoncé.
Oui. Le plus petit engagement est l’audit d’une application, au prix fixe affiché dans les offres. En dessous, il n’y a que le cadrage, qui ne se facture pas.
Oui, comme assistant de lecture et d’écriture, et seulement avec votre accord écrit. Tout ce qui sort passe par ma relecture avant de vous être remis, et c’est moi qui en réponds. Si vous refusez, je travaille sans : dites-le au cadrage, c’est pris en compte avant que le prix soit annoncé.
Racontez-moi votre parc applicatif - je vous dis ce que j’y ferais, quel format s’y prête et son prix, fixe et déjà affiché. Chiffrer votre modernisation, c’est ensuite le travail de l’audit. Et si rien ne se justifie, je vous le dis aussi.
Par mail
contact@fazeosoft.fr