Vos applications .NET font tourner l’entreprise. Reprenez la main.
Fazeo Software aide les PME, ETI et acteurs régulés à reprendre la main sur des applications anciennes : un état des lieux clair et chiffré de leur écart avec les pratiques actuelles d’abord, la modernisation ensuite, sans big-bang.
Forfait défini avant intervention · Périmètre maîtrisé · Restitution accessible aux décideurs
Plan type d’une application métier .NET dans sa plateforme. L’audit relève l’application ; ses voisines, hors périmètre, sont reconstituées et à confirmer. Chaque constat important du rapport dit d’où il vient.
Des années de modifications ont éloigné vos applications des pratiques actuelles. Cet écart se mesure, puis se résorbe.
Les versions vieillissent
Microsoft publie une politique de support pour chaque version de .NET ; pour .NET Framework 4.x, elle suit celle du système Windows qui l’héberge. Passé ce terme, plus de correctif de sécurité, sauf extension payante lorsqu’elle existe.
La connaissance s’est répartie
Au fil des modifications, des équipes et des contextes successifs, ce que l’on sait de l’application s’est réparti entre le code, la mémoire de chacun et les échanges de l’époque. La documentation n’a pas toujours pu suivre le rythme des évolutions.
Une décision difficile à éclairer
Tant que l’écart avec les pratiques actuelles n’est pas mesuré, le coût d’une modernisation reste difficile à estimer, et il est naturel que la décision attende.
Avec un état des lieux chiffré, on peut décider.
Des formats précis, au forfait, annoncés avant de commencer.
OffreFormatTarif, HT
Audit .NET
Votre parc analysé : l’écart avec les pratiques actuelles, les risques, l’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.
L’analyse inclut l’identification de vulnérabilités connues dans les dépendances et certains contrôles statiques d’hygiène de sécurité. Elle ne constitue ni un audit de sécurité exhaustif, ni un test d’intrusion, ni une certification de conformité.
Flash
1 application, éligibilité confirmée au cadrage
2 950 €HT
Ce que comprend cet audit
Le forfait flash couvre une application dont le périmètre technique est compatible avec ce format. L’éligibilité est confirmée lors du cadrage offert. Les applications particulièrement volumineuses, fragmentées ou contraintes font l’objet d’un devis adapté.
Ce qui est analysé
Le socle technique et les dépendances.
Le code, par analyse statique, avec les outils compatibles avec la technologie de l’application.
Les vulnérabilités connues dans les composants identifiables.
L’architecture, la maintenabilité et les tests.
Les risques, et les limites de l’analyse elle-même.
Ce que vous recevez
Un rapport avec des recommandations hiérarchisées.
Une première estimation de trajectoire et d’effort, avec ses hypothèses explicites.
Une restitution d’une heure.
Périmètre et conditions
Mode d’intervention : lecture et analyse, sans modifier le code applicatif ni déployer quoi que ce soit ; les compilations et analyses éventuelles se font dans un environnement isolé.
Volume : le nombre de dépôts et de projets n’est pas plafonné d’avance ; il est confirmé au cadrage, d’après la charge d’analyse estimée. Une application fragmentée (plusieurs dépôts ou projets difficiles à relier), contrainte (accès limité, compilation impossible) ou particulièrement volumineuse sort du forfait flash : un devis spécifique est établi avant tout démarrage.
Technologies acceptées : .NET Framework 4.x, Web Forms, MVC. Les services WCF sont étudiés au cas par cas, après une étude de faisabilité.
Accès : aux sources, aux dépendances, à la documentation disponible et, si possible, à un environnement où l’application se compile. Sans compilation possible, l’analyse est partielle et le rapport le dit.
Non couvert : ce qui n’est pas accessible ou n’a pas été confirmé au cadrage ; un audit de sécurité exhaustif, un test d’intrusion et une certification de conformité.
Parc
jusqu’à 5 applications
Prix fixe, chiffré au cadrageDevis ferme sous 72 h
Reprise en main
Pour l’application que des années de modifications successives rendent délicate à faire évoluer : remise sous tests des règles métier sensibles et rétro-documentation, sans rien réécrire. Vos équipes peuvent la reprendre.
Tests et documentation sont produits dans une branche de travail dédiée ; aucun déploiement en production n’est inclus par défaut.
Module critique
module délimité au cadrage : tests + documentation
3 250 €HT
Ce que comprend un module critique
Un module critique est un ensemble délimité lors du cadrage, qui porte des règles métier sensibles. Les tests portent sur les comportements prioritaires retenus à ce moment-là ; ils ne promettent pas une couverture exhaustive.
Livrables
Des tests automatisés sur les comportements retenus.
Une rétro-documentation technique du module.
Des consignes de reprise pour vos équipes.
Le tout dans une branche de travail dédiée, sans déploiement en production par défaut.
Prérequis
L’accès au code et à ses dépendances.
La possibilité de compiler l’application.
La disponibilité d’un référent métier.
Exclus
Une refonte du module.
Une couverture de tests complète.
La correction de toutes les anomalies déjà présentes.
Application complète
tests + documentation, sur un périmètre admissible
à partir de 6 500 €HT, forfait confirmé après qualification technique
Ce que comprend la reprise d’une application
Le prix affiché est un prix de départ, pour un périmètre admissible confirmé au cadrage. Une petite application et une grande application, modifiée pendant de longues années, ne demandent pas le même effort : hors de ce périmètre, la reprise fait l’objet d’un forfait sur devis, après qualification technique.
Ce qui détermine le périmètre
Le volume de code et le nombre de projets.
Le couplage entre les modules.
L’état des tests existants.
La possibilité de reconstruire l’environnement et de compiler l’application.
La disponibilité d’un référent métier.
Livrables
Des tests automatisés sur les comportements prioritaires retenus au cadrage, sans promesse de couverture totale de l’application.
Une rétro-documentation technique et des consignes de reprise.
Le tout dans une branche de travail dédiée, sans déploiement en production par défaut.
Exclus
Une refonte de l’application.
Une couverture de tests complète.
La correction de toutes les anomalies déjà présentes.
Modernisation par lots
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.
Les déploiements sont préparés avec vos équipes et réalisés selon les procédures convenues avec vous.
Un lot
périmètres de 2 à 4 semaines
6 500 à 13 000 €HT par lot, chiffré par l’audit
Aperçu du rapport
Synthèse pour la direction
Ce que la direction lit en premier dans un rapport d’audit, ici celui de Comptoir. Les mesures viennent d’un projet open source volontairement anonymisé ; le client, l’hébergement et la criticité sont reconstitués.
Comptoir paraît pouvoir se moderniser par étapes, à condition de poser d’abord un filet de tests sur le tunnel de vente.
RecommandationÀ moderniser
Les trois risques, par priorité (classement conditionnel)
Priorité 1 (conditionnelle)
Un tunnel de vente à la fois complexe et souvent modifié, sans lancement automatique des tests identifié dans le dépôt analysé.
Priorité 2
Des failles signalées dans des composants, un identifiant retiré du code mais encore lisible dans l’historique.
Priorité 3 (conditionnelle)
Un socle de génération historique, un hébergement à confirmer.
Voici un exemple de rapport d’audit : celui de Comptoir, une boutique en ligne en .NET Framework. Comptoir est le résultat de modifications successives. Le rapport mesure l’écart entre son état actuel et les pratiques d’aujourd’hui, puis propose de le résorber par étapes. Ouvrez-le axe par axe. Ce qui est mesuré, interprété ou reconstitué y est distingué, et un niveau « conditionnel » dépend d’une hypothèse reconstituée. La provenance des principaux constats est détaillée en bas de section.
Pour la direction
Les huit axes
Après la mesure
Synthèse pour la direction
Mesure du 28 septembre 2026 ; le dernier commit du dépôt analysé date de début 2023annexe 7. Origine des constats et points à confirmer : provenance, en bas de section.
Comptoir paraît pouvoir se moderniser par étapes, à condition de poser d’abord un filet de tests sur le tunnel de vente.
RecommandationÀ moderniser
Recommandation de l’auditeur, à confirmer sur les points marqués reconstitués ou partiels : hébergement, criticité du tunnel de vente, divergence de compilation des axes 3 et 5.
Les trois risques, par priorité (classement conditionnel)
Priorité 1 (conditionnelle)
Un tunnel de vente à la fois complexe et souvent modifié, sans lancement automatique des tests identifié dans le dépôt analysé.
Les six premiers points chauds, des fichiers à la fois complexes et souvent modifiés, portent tous sur la venteannexe 11 : ce sont les zones que les évolutions successives ont le plus sollicitées. Que le tunnel de vente porte le métier critique est reconstitué, à confirmer par entretien, et la priorité en dépend. Aucun pipeline versionné n’est identifié dans le dépôt analyséannexe 12 : sauf système externe, les tests ne se lanceraient pas automatiquement.
Priorité 2
Des failles signalées dans des composants, un identifiant retiré du code mais encore lisible dans l’historique.
L’outillage relève 195 alertes brutesannexe 48 : chacune signale une faille connue dans un composant, pas son exploitation. Le tri de l’auditeur retient huit composantsannexe 52-59. Un identifiant de service, retiré depuis, reste lisible dans l’historique du dépôtannexe 16 ; son état, actif ou non, est à faire vérifier par l’exploitant. Détection automatique, qualification partielle : ni audit de sécurité exhaustif, ni test d’intrusion (axes 2 et 3).
Priorité 3 (conditionnelle)
Un socle de génération historique, un hébergement à confirmer.
Décision attendue. Dans le scénario de cette démonstration : engager le lot 1, la reprise en main du tunnel de vente, en novembre 2026 ; chaque lot suivant se déciderait à la livraison du précédent.
Axe 1 sur 8
Support du socle et écart de versions des dépendances
Exposition élevéeniveau conditionnel : il tient à l’hypothèse d’hébergement, reconstituée
Couverture de la mesure : partielle. Une dépendance sur les 100 déclarées est absente de la base de versions : son écart de version n’est ni confirmé ni écarté. L’hébergement (système, serveur d’application, base de données) ne se lit pas dans le code : il est reconstitué.
Constat
Tous les projets ciblent .NET Framework 4.7 avec ASP.NET MVC 5 et Web API 2annexe 18. Ces technologies appartiennent à une génération historique de l’écosystème Microsoft.
Sur 100 dépendances déclarées, 99 sont évaluées : 24 à jour, 4 à rattraper d’un correctif, 46 à rattraper d’une version mineure, 25 à rattraper d’au moins une version majeureannexe 45. 7 composants sont dépréciés par leur éditeurannexe 47. Un écart de version n’est pas une vulnérabilité : les failles signalées sont à l’axe 2.
Aucune brique n’est classée comme déjà hors support. L’échéance du 12 janvier 2027, sous l’hypothèse d’hébergement, reste à traiter : ses effets sur les correctifs de sécurité dépendent des options de support, à vérifier avec l’exploitant. 25 dépendances à rattraper d’une version majeure ou plus, ce sont autant de changements de comportement possibles si on les traite d’un coup.
Pourquoi ce niveau
Exposition élevée dès qu’une brique sort du support dans les 12 mois, immédiate si elle en est déjà sortie ou si l’échéance tombe dans les 3 mois. Sous l’hypothèse d’hébergement, l’échéance tombe environ trois mois et demi après la mesure du 28 septembre 2026, juste au-delà du seuil d’exposition immédiate : élevée ; à partir du 12 octobre 2026, la même hypothèse donnerait une exposition immédiate. Sans elle, le seuil ne classe pas l’axe. Les 7 composants dépréciés ne sont pas assimilés à des briques hors support : leur politique de support n’est pas détaillée.
Recommandation
Faire confirmer le système hôte par l’exploitant. Si Windows Server 2016 est confirmé, prévoir sa migration, ou vérifier les options de support, avant le 12 janvier 2027. Recibler vers .NET Framework 4.8 au lot 2, après vérification de la compatibilité. Rattraper les dépendances par ordre d’exposition plutôt qu’en bloc.
Qui et quand
L’exploitant, avant le 12 janvier 2027 si l’hypothèse se confirme. Lot 2 pour le framework et les dépendances. Information manquante. Le système d’exploitation réellement utilisé.
Axe 2 sur 8
Vulnérabilités connues des composants
Exposition élevéeniveau interprété, sur des alertes d’outillage dont l’exploitabilité reste à qualifier
Couverture de la mesure : partielle. 54 % des éléments inventoriés n’ont pas d’identifiant exploitable pour le rapprochement automatique avec les bases de failles : pour eux, l’absence d’alerte ne prouve rien. Les composants web gérés par npm ne sont pas couverts.
Constat
L’outillage relève 195 alertes brutesannexe 48 : 11 critiques, 74 élevées, 107 moyennes, 3 faibles. C’est une détection automatique : une alerte signale une faille connue dans un composant, pas son exploitation dans l’application. Le tri de l’auditeur retient huit composantsannexe 52-59, qualification manuelle qui change d’unité, des alertes aux composants.
Cinq bibliothèques tierces portent une faille critiqueannexe 13 : un comptage interprété par l’auditeur à partir des alertes. Une de ces bibliothèques est dans l’outillage de construction, non livrée. Pour l’une d’elles, celle des expressions dynamiques, l’analyse du code la dit atteignable depuis le code de l’application.annexe 14 Ce n’est pas la preuve que la faille est exploitable, qui reste à qualifier.
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. Figurer à ce catalogue ne dit pas qu’une faille est exploitable dans cette application.
Le risque réel peut être plus étroit que les 195 alertes brutes, mais il n’est ni nul ni mesuré. L’exposition reste à qualifier, en priorité pour l’API partenaires (existence et exposition à confirmer) ; les 54 % d’éléments sans identifiant exploitable ne sont ni écartés ni confirmés vulnérables.
Pourquoi ce niveau
Exposition élevée dès qu’une faille de gravité élevée touche un composant atteignable, immédiate dès qu’une faille critique atteignable est activement exploitée. « Atteignable » vient d’une analyse de code, non d’un test d’exploitation. Les 4 alertes du catalogue qualifiées sont de gravité moyenne ; les 2 autres restent à confirmer : le niveau s’arrête à « élevée » sous cette réserve.
Recommandation
En gains rapides, les correctifs de même version majeure : expressions dynamiques, graphiques, journalisation. En priorité, qualifier l’exposition de l’API partenaires. Si l’enjeu l’exige (données sensibles, exposition publique), faire appel à une expertise spécialisée en sécurité des systèmes d’information (SSI).
Qui et quand
Gains rapides, puis l’API partenaires en priorité, hors lots. Le reste au lot 2. Information manquante. L’exposition réelle des composants retenus, et la nature des 2 alertes du catalogue restées à confirmer.
L’analyse inclut l’identification de vulnérabilités connues dans les dépendances et certains contrôles statiques d’hygiène de sécurité. Elle ne constitue ni un audit de sécurité exhaustif, ni un test d’intrusion, ni une certification de conformité. Aucune assurance globale sur la sécurité du système n’en découle ; une expertise de sécurité (SSI) spécialisée est recommandée dès que l’enjeu l’exige.
Axe 3 sur 8
Hygiène de sécurité applicative
Écart marquéniveau interprété : il passerait à « écart important » si l’identifiant de service est confirmé actif
Couverture de la mesure : partielle. Environ 240 fichiers de configuration ou de script et 3 500 fichiers source ont été soumis aux contrôles. Réserve : l’analyse des règles de code (Roslyn) a rencontré 36 erreurs de compilation, alors que la reconstruction de la solution s’est faite sans erreur (axe 6). Divergence non expliquée : les contrôles qui en dépendent sont partiels.
Constat
Grille de 25 contrôles de pratiques actuelles, 22 applicables, dont 13 signalent un écartannexe 61. Ce sont des contrôles statiques et automatiques : un contrôle qui signale un écart est un signal à qualifier, pas une faille confirmée.
14 lignes signalées comme secret en clair dans les fichiers contrôlés : à la relecture, 12 faux positifs et 2 valeurs d’exemple (12 + 2 = 14), donc aucune clé réelle identifiée parmi ces 14 lignesannexe 64. Mode débogage actif dans 14 configurationsannexe 31 : un autre décompte, en configurations et non en lignes.
Constat distinct.Un identifiant de service, retiré depuis, reste lisible dans l’historique du dépôt.annexe 16 Il est tenu pour distinct de ces 14 lignes, ce qui reste à confirmer ; son état, actif ou non, n’est pas établi.
Ce que ça implique
Un identifiant retiré du code reste lisible dans l’historique pour qui a une copie du dépôt. S’il était encore actif, il pourrait donner accès au service concerné : l’exploitant doit le vérifier.
Pourquoi ce niveau
Écart marqué dès qu’un secret apparaît en clair dans l’historique, important si un secret actif est en clair. L’état de l’identifiant n’étant pas établi, le niveau est « marqué », sous cette condition.
Recommandation
Faire vérifier l’identifiant de service par l’exploitant, et le révoquer s’il est actif (gain rapide). Au lot 2 : qualifier le schéma de hachage des mots de passe, revoir désérialisations et certificats.
Qui et quand
L’exploitant pour l’identifiant, en gain rapide. Le reste au lot 2. Information manquante. L’état de l’identifiant, et les contrôles de la grille qui reposent sur l’analyse Roslyn.
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 (périmètre complet à l’axe 2), et sa couverture est partielle. Aucune assurance globale n’en découle ; une expertise de sécurité (SSI) spécialisée reste recommandée dès que l’enjeu l’exige.
Axe 4 sur 8
Architecture macro
Écart léger, mesure partielleniveau interprété
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é.
Constat
Une vingtaine de projets, 78 références entre eux, aucun cycle, aucune inversion de dépendance détectée (couverture partielle, voir ci-dessus).annexe 9
4 modules d’extension sur une douzaine référencent directement le site, là où le découpage visé passe par le 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.
Ce que ça implique
Aucun cycle mesuré : une modernisation par morceaux est envisageable, en commençant par le noyau, à condition d’en confirmer d’abord les couches. Le découplage de tous les modules n’est pas acquis : seuls quatre modules sont identifiés, comme premiers points à couper.
Pourquoi ce niveau
Écart marqué dès qu’il existe des cycles entre couches ou une base partagée sans contrat, important si aucune séparation n’est exploitable. Le critère de la base partagée n’est pas détaillé. Aucun cycle ni inversion mesurés, mais quatre références directes au site sont relevées et les couches ne sont pas déclarées : écart léger plutôt qu’aligné. Le niveau reste provisoire tant que les couches ne sont pas déclarées : c’est autant une limite de la mesure qu’un écart de l’application.
Recommandation
Déclarer les couches, puis, si elles se confirment, couper les quatre références directes avant toute migration de la présentation.
Qui et quand
Lot 3. Information manquante. Les couches réelles de l’application, que les noms de projets ne permettent pas d’établir.
Axe 5 sur 8
Architecture interne et maintenabilité du code
Écart légerniveau interprété ; seuil chiffré non franchi (11 % pour 20 %)
Priorité haute, conditionnelle à une criticité reconstituée. Elle dépend du tunnel de vente comme métier critique : à confirmer par entretien.
Couverture de la mesure : partielle. Analyse faite avec Roslyn, la plateforme de compilation de Microsoft. Réserve : 36 erreurs de compilation, alors que la reconstruction de la solution s’est faite sans erreur (axe 6) : divergence non expliquée, complexité et maintenabilité approximatives, à lire comme partielles.
Constat
11 % des lignes utiles sont dans des fichiers à faible maintenabilité, sous le seuil d’alerte de 20 %annexe 72.
Les six premiers points chauds de l’analyse, des fichiers à la fois complexes et souvent modifiés, portent tous sur la vente : fiche produit, panier, commandes, prise de commandeannexe 11. Ce sont les zones que les évolutions successives ont le plus sollicitées. Que le tunnel de vente porte le métier critique est reconstitué : à confirmer par entretien.
Dans le fichier de prise de commande, la méthode qui enregistre la commande atteint la valeur la plus basse de l’indice de maintenabilité (0 sur 100 ; plus l’indice est bas, plus la méthode demande d’effort pour être relue et modifiée)annexe 76, valeur calculée par l’analyse Roslyn et donc approximative ; seul le choix de cette méthode relève de l’interprétation.
Ce que ça implique
Si le tunnel de vente porte bien le métier critique, ce que l’entretien doit confirmer, une modification des points chauds de la vente serait risquée tant que des tests n’en vérifient pas l’effet.
Pourquoi ce niveau
Écart marqué au-delà de 20 % du code en faible maintenabilité ; ce seuil n’est pas franchi (11 %, sur la partie analysée) et aucun critère d’écart important n’est défini pour cet axe. Le niveau est « léger » plutôt qu’« aligné » parce que 11 % du code reste en faible maintenabilité et qu’une méthode atteint la valeur la plus basse de l’indice. La priorité est un autre critère : elle est haute dès que les points chauds concentrent le métier critique. Ce second critère associe une concentration technique, interprétée à partir de mesures partiellesannexe 11, et une criticité métier seulement reconstituée, sans entretien. Priorité haute, par interprétation, et sous la condition de cette criticité ; sans elle, le seul critère chiffré ne la justifierait pas, et la priorité serait à revoir.
Recommandation
Éviter de restructurer avant d’avoir figé par des tests le comportement actuel du tunnel de vente. Découper ensuite, fichier par fichier, sous ce filet.
Qui et quand
Lot 1, puis chaque lot. Information manquante. La criticité métier du tunnel de vente, à recueillir par entretien.
Axe 6 sur 8
Testabilité et filet de sécurité
Écart marquéniveau mesuré sur le dépôt analysé, repris tel quel ; le critère « non documentée » est lu par absence dans ce dépôt
Couverture de la mesure : limitée au dépôt analysé. Les tests existants ont été inventoriés, pas exécutés, et un système d’intégration hors dépôt n’est ni exclu ni établi : ce sont des limites de l’audit.
Deux opérations distinctes, deux résultats. L’analyse de code par Roslyn (axes 3 et 5) a rencontré 36 erreurs de compilation. La reconstruction de la solution (ci-dessous) s’est terminée sans erreur. Les deux résultats peuvent être compatibles, mais cette démonstration ne l’établit pas. La divergence n’est pas expliquée ici et reste à investiguer : outils et versions, mode d’analyse, configuration Debug ou Release, projets inclus, dépendances chargées, cibles, date d’exécution, à comparer. Les constats des axes 3 et 5 qui reposent sur Roslyn sont donc partiels.
Constat
L’application se reconstruit hors production en moins d’une minute : une vingtaine de projets, 83 assemblages produits (le décompte dépasse le nombre de projets), sans erreurannexe 77.
Aucun pipeline versionné identifié dans le dépôt analysé ; 5 scripts de construction lancés à la main.annexe 12 L’absence dans un dépôt ne prouve pas l’absence d’un système d’intégration externe.
5 projets de tests et 160 fichiers de test existent et ont été inventoriés ; leur lancement automatique n’est pas identifié dans le dépôt analysé.annexe 43
Ce que ça implique
Le code source se reconstruit et des tests existent : c’est un point d’appui pour la suite. Leur état est inconnu, puisqu’ils n’ont pas été exécutés, et ils ne protègent des régressions que s’ils sont lancés régulièrement.
Pourquoi ce niveau
Écart marqué si la reconstruction hors production est possible mais non documentée, important si elle est impossible. Un pipeline ou une documentation de construction hors dépôt, s’ils existent, changeraient ce constat.
Recommandation
Écrire la construction dans un pipeline versionné, qui lancerait les tests, après avoir vérifié qu’aucun système d’intégration externe n’existe déjà. Constater l’état des tests existants, puis les relancer.
Qui et quand
Gain rapide pour le pipeline, lot 1 pour les tests. Information manquante. L’existence d’un système d’intégration externe au dépôt, d’une documentation de construction, l’état des tests, et la cause de la divergence avec l’analyse Roslyn.
Axe 7 sur 8
Connaissance et documentation
Écart léger, mesure partielleniveau interprété, la mesure suggère « réparti » ; le scénario de maintenance externe n’y est pas pris en compte
Couverture de la mesure : complète sur le dépôt analysé, nulle hors dépôt. Réserve : les trois ans observés précèdent le dernier commit, pas l’audit, et un dépôt figé est mesuré à la date où il s’est figé.
Constat
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 mesure suggère une connaissance répartie entre les signatures (un indice, pas une mesure de la connaissance) ; elle ne dit pas qui la détient aujourd’hui.
Aucun commit dans le dépôt analysé depuis début 2023annexe 10. Aucun document d’architecture identifié dans le dépôt analysé.annexe 83 Cela ne dit rien d’une documentation éventuellement tenue ailleurs. C’est un écart aux pratiques actuelles, que le lot 1 prévoit de combler pour le tunnel de vente.
Scénario de la mise en situation, non mesuré : la maintenance serait assurée par un prestataire externe, sans développeur interne.
Ce que ça implique
Dans le scénario de la mise en situation, la maintenance serait confiée à un prestataire externe. Un document d’architecture et un guide de reprise sont utiles à toute équipe, en place ou nouvelle. Aucun document d’architecture n’est identifié dans le dépôt analysé (sauf documentation existante ailleurs, à vérifier) ; le lot 1 prévoit l’un et l’autre pour le tunnel de vente.
Pourquoi ce niveau
Écart marqué dès que la connaissance d’un module critique repose sur une seule personne, important si cette connaissance n’est plus détenue au sein de l’entreprise. Le premier critère n’est pas évalué module par module ; la mesure globale n’en indique pas de franchi. Le second relève du scénario reconstitué et n’est pas évalué, faute d’entretien : ce critère serait à réexaminer si le scénario (aucun développeur interne) était confirmé. Écart léger plutôt qu’aligné, la mesure datant du gel du dépôt.
Recommandation
Chaque lot livre sa documentation à jour. Le lot 1 prévoit la documentation d’architecture et le guide de reprise du tunnel de vente. Le plan est conçu pour pouvoir être repris par l’équipe en place ou par un autre prestataire, dans la limite de la documentation produite.
Qui et quand
Chaque lot, dès le lot 1. Information manquante. La documentation tenue hors dépôt, et l’organisation réelle de la maintenance, notamment où elle s’effectue puisque le dépôt analysé est figé.
Axe 8 sur 8
Recommandation et effort de reprise
À moderniserrecommandation de l’auditeur, conditionnelle aux réserves ci-dessous
Couverture de la mesure : absente, à dessein. Aucun outil ne produit la recommandation : l’auditeur l’écrit à partir des sept autres axes, dont il reprend les réserves. Elles portent sur la divergence de compilation des axes 3 et 5, la couverture de l’axe 6 limitée au dépôt analysé, le niveau conditionnel de l’axe 1 et la priorité conditionnelle de l’axe 5.
Quatre trajectoires sont possibles
À maintenir
Non retenu à ce stade : le support du socle dépend de l’hébergement, et les failles signalées dans les composants restent à traiter.
À reprendre
Non retenu : suffirait si l’écart ne portait que sur le code. Ici il porte aussi sur le socle (.NET Framework 4.7), dont le support dépend du système hôte.
À remplacer
Non retenu : mettrait de côté un code de l’ordre de 270 000 lignes (volume arrondi) qui se reconstruit, un acquis que la modernisation conserve.
À moderniser
Retenu. Sans cycle mesuré entre projets (axe 4, couverture partielle) et avec une application qui se reconstruit (axe 6), la modernisation progressive apparaît comme une trajectoire pertinente à ce stade, sous réserve de confirmer les hypothèses et d’étudier les alternatives.
Effort. Estimation reconstituée : trois lots pour traiter d’abord les priorités (tests, composants, sécurité) et préparer, puis la migration de la présentation. Le plan d’action dit ce que cette estimation suppose.
D’abord le filet, ensuite les composants, puis le socle.
La trajectoire est conçue pour pouvoir s’arrêter après chaque lot, sous réserve des dépendances indiquées plus bas. Prix, calendrier et découpage sont reconstitués : l’estimation éclaire la décision, et le forfait qui engage est celui du devis, pour un périmètre convenu. Rien ne garantit qu’une migration se fasse sans risque ni sans interruption.
Serveur hôte (si confirmé), migration ou options de support avant le 12 janvier
Lot 3
Migration, 4 lots au moins
jusqu’à 8 lots
Comment lire ce calendrier
Calendrier illustratif et reconstitué : il montre une trajectoire possible, pas une date promise.
Trois notions distinctes : l’effort estimé (le travail à fournir), la durée calendaire (le temps écoulé, validations et disponibilités comprises) et le délai contractuel (fixé au devis, hors de ce rapport). Ici, les semaines sont un effort estimé, les barres une durée calendaire illustrative.
Les estimations dépendent de la connaissance acquise et seront revues à la livraison de chaque lot. Leur cohérence avec la taille de l’application n’est pas établie, et la barre du lot 3 (un mois pour 4 semaines d’effort) ne montre aucune marge de validation.
Les barres de la migration ne reposent sur aucune estimation d’effort : 4 lots sur 4 mois, puis jusqu’à 4 de plus, à titre d’illustration. Les gains rapides et la qualification de l’API partenaires, hors lots, n’ont pas d’effort estimé.
Le lot 1, le filet de tests, précède toute restructuration. Les couches déclarées au lot 3 précèdent la migration de la présentation, et le chiffrage de la suite attend le lot 3. Les autres dépendances, par exemple entre le reciblage du lot 2 et la préparation du lot 3, ne sont pas établies.
Le découplage de tous les modules n’est pas acquis (axe 4).
Chaque lot comprend ses validations, des tests de non-régression et un plan de retour arrière.
Bascules et essais se planifient avec l’exploitant, lot par lot : aucune interruption n’est exclue d’avance.
Les lots proposés
Lot 1 2 semaines d’effort
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 des parcours couverts, à valider avec l’exploitant. Constat de l’état des tests existants et relance, documentation d’architecture et guide de reprise.
Lot 2 4 semaines d’effort
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 vers .NET Framework 4.8 si la compatibilité se confirme.
Lot 3 4 semaines d’effort
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. Quatre modules branchés sur le site sont à détacher. Objectif : que l’application continue de tourner telle quelle, dans la limite de ce que couvrent les tests de non-régression.
Suite 4 à 8 lots
Migration progressive de la présentation vers ASP.NET Core. Environ 680 vues et 170 contrôleurs. Le nombre de lots et le chiffrage de chacun, au forfait par lot, ne seront établis qu’à partir de ce que le lot 3 aura révélé.
Gains rapides
Faire vérifier par l’exploitant l’identifiant de service retrouvé dans l’historique, et le révoquer s’il est encore valide.
Mettre à jour les trois bibliothèques dont la faille critique se corrige sans changer de version majeure, puis rejouer une commande complète avant la mise en production.
Retirer le mode débogage et déclarer la protection des cookies dans les configurations concernées.
Écrire la construction dans un pipeline versionné, qui lancerait les tests, après avoir vérifié qu’aucun système d’intégration externe n’existe déjà.
Ce que le rapport déconseille
Une réécriture complète. Réécrire expose à perdre ce que l’application fait aujourd’hui, y compris les cas particuliers ajoutés au fil des modifications.
Une migration d’un seul tenant. Sans tests de non-régression, il serait difficile de savoir ce qui a cassé.
Mettre à jour d’un coup toutes les dépendances dont une version majeure plus récente existe. 25 dépendances qui changent de version majeure en même temps se testent difficilement.
Un convertisseur automatique seul. Il transpose le code sans vérifier qu’il se comporte comme avant.
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. Le projet est volontairement anonymisé : ni son nom, ni la version analysée ne sont publiés. Ce qui est mesuré ou interprété vient de cet audit. Le reste est une mise en situation fictive, donc reconstitué : client, hébergement, criticité métier, prestataire, chiffrage, calendrier. Aucun entretien n’a eu lieu.
Ce que vous pouvez vérifier ici. Les petits numéros renvoient aux fichiers de mesure et d’interprétations du rapport complet, non reproduits dans cette page ; un élément reconstitué n’en a pas. Le projet source étant anonymisé, ces mesures ne sont pas vérifiables publiquement, et cette démonstration n’est pas reproductible par le lecteur. La provenance des principaux constats dit ce qui est établi et ce qui ne l’est pas.
Deux repères et une priorité. L’exposition (axes 1 et 2, des faits extérieurs à l’application) se lit : maîtrisée, à suivre, élevée, immédiate. L’écart aux pratiques actuelles (axes 3 à 7) se lit : aligné, écart léger, écart marqué, écart important. Les seuils vers les deux derniers niveaux de chaque repère sont fixés d’avance, axe par axe, quand l’axe en comporte. La frontière entre les deux premiers, et l’application d’un critère qui dépend d’une hypothèse, relèvent d’une interprétation, dite dans « Pourquoi ce niveau ». La priorité dit quoi traiter d’abord : dans la synthèse, c’est un rang (1, 2, 3), et la « priorité haute » de l’axe 5 correspond au rang 1 ; elle dépend du métier, et reste conditionnelle quand elle repose sur une hypothèse reconstituée (criticité métier, hébergement). « Mesure partielle » signale une couverture limitée : le niveau reste provisoire. La comparaison entre audits reste indicative : couverture et hypothèses varient. Un niveau « conditionnel » est confirmé ou revu avec son hypothèse ; la jauge porte l’encre dont le niveau est établi, la condition est signalée à côté.
Un écart à résorber. Ce rapport décrit l’écart entre l’application, telle que des années de modifications l’ont façonnée, et les pratiques actuelles. Il ne juge ni l’application ni celles et ceux qui l’ont construite et maintenue.
Provenance et vérification
Provenance des principaux constats et points à confirmer
Pour chacun des principaux constats : son statut, la limite connue et ce qu’un audit chez un client devrait confirmer. Ce qui n’est pas donné ci-dessous comme précisé (annexe, outil, version, commande, périmètre de comptage, date) ne l’est pas dans cette démonstration.
Versions du socle
Statut.Mesuré, annexe 18 : versions ciblées par tous les projets.
Limite. Lecture du dépôt analysé : elle ne dit pas ce qui est déployé.
À confirmer. Les versions déployées et le système Windows hôte, dont dépend le support de .NET Framework 4.7.
Limite. « Windows Server 2016 » est une hypothèse de la mise en situation. Si elle est confirmée, la fin du support étendu est le 12 janvier 2027. Le niveau de l’axe 1 en dépend.
À confirmer. Le système, le serveur d’application et la base de données réellement utilisés, auprès de l’exploitant, et les options de support éventuelles.
Dépendances à rattraper
Statut.Mesuré, annexes 45 et 47 : écarts de version, composants dépréciés.
Limite. Une dépendance est absente de la base de versions (axe 1) ; composants npm non couverts (axe 2).
À confirmer. La dépendance absente, et l’inventaire des binaires et scripts copiés dans le dépôt.
Alertes de vulnérabilités et tri
Statut.Mesuré, annexe 48 (détection automatique) et annexe 50 (catalogue des failles activement exploitées). Interprété, annexes 52 à 59 (tri à huit composants), 13 et 14 (cinq bibliothèques à faille critique, dont une atteignable depuis le code). 54 % d’éléments sans identifiant exploitable : limite de couverture de l’axe 2, sans annexe.
Limite. Non donnés : les failles confirmées et les faux positifs ; le lien entre les 11 alertes critiques, les cinq bibliothèques et les huit composants ; le nombre d’éléments inventoriés (dénominateur des 54 %) et son recouvrement avec les 100 dépendances de l’axe 1. Le décompte de trois bibliothèques corrigibles sans changer de version majeure (gains rapides) n’a ni statut ni annexe, et son lien avec les cinq bibliothèques à faille critique, dont une non livrée, n’est pas détaillé.
À confirmer. L’exposition réelle (l’existence et l’exposition de l’API partenaires, retenue en priorité : statut non précisé), l’exploitabilité des composants retenus, et les 2 alertes du catalogue restées à confirmer. Si l’enjeu l’exige, une expertise de sécurité (SSI) spécialisée.
Secrets et historique
Statut.Interprété, annexe 64 (14 lignes relues, aucune clé réelle identifiée) et annexe 16 (identifiant de service retiré, constat distinct). Mesuré, annexe 31 (mode débogage dans 14 configurations).
Limite. Les 14 lignes et les 14 configurations sont deux décomptes distincts. Le périmètre de la recherche dans l’historique n’est pas précisé.
À confirmer. L’état de l’identifiant, par l’exploitant (à révoquer s’il est actif), et qu’il ne figure pas parmi les 14 lignes.
Contrôles de la grille
Statut.Mesuré, annexe 61. Environ 240 fichiers de configuration ou de script et 3 500 fichiers source soumis aux contrôles : sans statut ni annexe.
Limite. Contrôles statiques et automatiques. Ceux qui reposent sur l’analyse Roslyn sont partiels, sans que lesquels soient précisés.
À confirmer. Lesquels reposent sur Roslyn, le détail de chaque contrôle qui signale un écart (non reproduit dans cette page) et l’origine des actions citées au plan (hachage des mots de passe, désérialisations, certificats, protection des cookies).
Erreurs Roslyn et reconstruction
Statut. 36 erreurs de compilation rencontrées par l’analyse Roslyn (axes 3 et 5) : sans statut ni annexe. Reconstruction de la solution sans erreur, 83 assemblages : mesuré, annexe 77.
Limite. La divergence n’est pas expliquée : les constats des axes 3 et 5 qui reposent sur Roslyn sont partiels. Ce que compte « assemblage » (83 pour une vingtaine de projets) : non précisé.
À confirmer. Comparer les deux exécutions avant de s’appuyer sur ces constats.
Maintenabilité et points chauds
Statut.Mesuré, annexe 72. Interprété, annexe 11 (points chauds) et annexe 76 (choix de la méthode d’enregistrement de la commande, dont l’indice, calculé par Roslyn, est partiel).
Limite. Mesures issues de l’analyse Roslyn, donc partielles. Les points chauds établissent une concentration technique, pas une criticité métier. Le volume de l’ordre de 270 000 lignes cité à l’axe 8 n’a ni annexe ni périmètre de comptage précisé, et rien ne démontre que toutes ces lignes soient du code métier.
À confirmer. La criticité métier, par entretien, et les mesures, après investigation de la divergence de compilation.
Architecture macro
Statut.Mesuré, annexes 9, 69 et 70. Couches non reconnues (60 % des projets) et 16 points d’entrée : sans annexe.
Limite. Couches déduites des noms de projets (axe 4). Critère de la base partagée non détaillé.
À confirmer. Les couches réelles, par déclaration, et le rôle des quatre références directes au site.
Pipeline, tests et documentation
Statut.Mesuré sur le dépôt analysé : annexes 12, 43, 83 et 10.
Limite. L’absence dans un dépôt ne prouve pas l’absence ailleurs : système d’intégration externe, documentation hors dépôt. Tests inventoriés, non exécutés.
À confirmer. Auprès de l’organisation : l’intégration continue et la documentation qui existeraient hors dépôt, et l’état des tests.
Connaissance et historique
Statut.Mesuré sur le dépôt analysé, annexe 80. Gel du dépôt : la synthèse et l’axe 7 citent des annexes différentes (7 et 10).
Limite. Une signature n’est pas une personne, et elle dit qui a écrit, pas qui sait. Le dénominateur des 30 % n’est pas précisé. La mesure est globale, non par module.
À confirmer. Par entretien : qui détient aujourd’hui la connaissance de chaque module critique, et où s’effectue la maintenance, le dépôt analysé étant figé.
Criticité métier et prestataire
Statut.Reconstitué, sans annexe : le tunnel de vente porte le métier critique ; la maintenance est assurée par un prestataire externe, sans développeur interne.
Limite. Scénario de la mise en situation, aucun entretien. La priorité haute de l’axe 5 en dépend, les conséquences de l’axe 7 sont au conditionnel, et le critère de perte de la connaissance au sein de l’entreprise n’est pas évalué.
À confirmer. Par entretien : les processus réellement critiques et l’organisation de la maintenance.
Calendrier et chiffrage
Statut.Reconstitué, sans annexe : lots, semaines, calendrier de novembre 2026 à octobre 2027, 4 à 8 lots de migration.
Hors statut reconstitué. Environ 680 vues et 170 contrôleurs : volume de l’application auditée, sans statut ni annexe.
Limite. Calendrier illustratif. Les estimations dépendent de ce que les lots précédents auront appris, et le découplage de tous les modules n’est pas acquis.
À confirmer. Les disponibilités de chacun, les validations côté client, le périmètre convenu et le devis.
Trois temps, sans engagement au départ.
1
Un cadrage de 45 minutes, offert
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 72 h.
2
L’intervention, au forfait
L’audit mesure l’existant par rapport aux pratiques actuelles, sans modifier le code applicatif en production. La reprise en main peut ajouter des tests et de la documentation dans une branche dédiée. La modernisation intervient sur le code et prépare les déploiements, réalisés selon les procédures validées avec vos équipes. Le périmètre est écrit dans le devis ; toute demande supplémentaire, ou toute hypothèse du cadrage qui se révèle inexacte, passe par un avenant accepté avant tout travail.
3
La restitution, en français clair
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.
Votre code reste votre code.
Par défaut, l’intervention se fait dans votre environnement : vos sources ne quittent pas votre système d’information.
Aucune de vos sources n’est confiée à un service d’intelligence artificielle externe sans votre accord écrit. Elles ne servent pas à entraîner de modèle, sous réserve des garanties contractuelles et de la configuration des services autorisés, identifiés avec vous au cadrage.
Les copies de travail détenues par Fazeo sont supprimées selon les modalités et délais convenus au contrat, sous réserve des obligations légales applicables. Une attestation de suppression peut être fournie selon le périmètre concerné.
NDA signé volontiers, dès le premier échange.
Pour les environnements les plus sensibles, un mode d’intervention entièrement hors ligne, outillage compris, est proposé sur demande et sur devis : sans réseau, l’actualisation des bases de vulnérabilités et certains contrôles qui dépendent de services externes peuvent être limités. Un mode sans intelligence artificielle est possible si votre contexte l’exige ; s’il modifie sensiblement la charge, le devis est adapté au périmètre.
Un interlocuteur unique, qui écrit le code et le rapport.
LFLéo
Nom
Léo Fazendeiro
Fonction
Fondateur, Fazeo Software (EURL)
Parcours
11 ans de développement logiciel, dont 6 ans sur .NET/C#.
Domaines
Applications métier, banque et systèmes d’information financiers, logiciels destinés aux services départementaux d’incendie et de secours (SDIS), applications historiques ASP.NET, intégrations REST et authentification centralisée, SQL Server, Azure DevOps et GitLab CI.
Applications
.NET Framework 4.x, Web Forms, MVC. Les services WCF sont étudiés au cas par cas, après une étude de faisabilité.
Dernière mission longue
Groupe Crédit Agricole
Évolution et maintien d’un intranet ASP.NET utilisé par environ 700 collaborateurs, coexistence .NET Framework 4.8 et .NET 8, authentification centralisée et intégrations d’applications métier.
Une constante
J’ai fait évoluer et maintenu des applications ASP.NET historiques. De la documentation et du code que vos équipes peuvent reprendre sans moi.
Où
Basé à Bayonne. Interventions sur site au Pays Basque et dans les Landes, à distance partout en francophonie.
Nous avons déjà un prestataire. Pourquoi un audit externe ?
L’audit ne modifie pas le code applicatif en production : il analyse, il chiffre, il produit un rapport. Votre prestataire garde la main. L’audit ne juge pas le travail de celles et ceux qui l’ont fait évoluer : il mesure l’écart de l’application avec les pratiques actuelles, et les choix qu’on y lit se comprennent par le contexte de leur époque. Je vends aussi les lots de modernisation : l’audit est au forfait et facturé à la remise du rapport, que sa conclusion soit « modernisez par étapes » 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.
Pourquoi afficher les prix ?
Parce qu’un prix annoncé d’avance se discute avant de commencer, pas après. Le forfait porte sur un périmètre écrit au cadrage : à périmètre constant, vous payez le montant du devis. Si le besoin change, ou si une hypothèse du cadrage se révèle inexacte, un avenant est proposé et ne démarre qu’avec votre accord.
Nous sommes une petite structure. C’est pour nous ?
Oui. Le plus petit engagement est l’audit flash d’une application, au forfait affiché dans les offres, dès que son périmètre est compatible avec ce format : le cadrage le confirme. En dessous, il n’y a que le cadrage, qui ne se facture pas.
Utilisez-vous l’intelligence artificielle sur notre code ?
Oui, comme assistant de lecture et d’écriture. Tout envoi de vos sources à un service externe est soumis à votre accord écrit : les outils autorisés sont identifiés avec vous au cadrage, et un outil qui traite vos sources sans les transmettre hors de votre système d’information n’est pas un service externe. Tout ce qui sort passe par ma relecture avant de vous être remis, et c’est moi qui en réponds. Si votre contexte l’exige, je travaille sans IA : dites-le au cadrage. Si cela modifie sensiblement la charge, le devis est adapté au périmètre.
Commencez par 45 minutes. Offertes, sans engagement.
Racontez-moi votre parc applicatif - je vous dis ce que j’y ferais, quel format s’y prête et son prix, fixe une fois le périmètre défini. Chiffrer votre modernisation, c’est ensuite le travail de l’audit. Et si rien ne se justifie, je vous le dis aussi.