Que contient une estimation de réécriture logicielle ?

Une estimation de réécriture doit décrire l'incertitude liée au comportement, pas récompenser la personne qui a compté le dépôt le plus vite. Le nombre de lignes compte, puisque quelqu'un devra les examiner et les remplacer, mais il ne constitue qu'une donnée d'entrée. La profondeur des branchements, les intégrations externes, la sémantique des données, les tâches d'exploitation et la surface disponible pour les tests de parité pèsent souvent davantage que la taille brute.

J'ai vu de petits moteurs de facturation prendre plus de temps à remplacer que d'immenses applications de reporting. Le petit système cachait ses règles dans des branches imbriquées, stockait des états intermédiaires dans des tables que personne n'avait documentées et appelait des services dont le comportement changeait à la clôture mensuelle. Le grand répétait des schémas CRUD simples et possédait des journaux de requêtes propres. Toute estimation qui commence et finit par "300 000 lignes" colle une étiquette précise sur un travail qui n'a pas été mesuré.

Ce que le nombre de lignes peut révéler

Le nombre de lignes mesure utilement le volume à examiner, mais il ne mesure pas à lui seul la difficulté d'une réécriture. Une équipe a tout de même besoin d'un comptage reproductible, car la taille du dépôt, le nombre de fichiers et les lignes exécutables se retrouvent souvent mélangés pendant les discussions commerciales.

Définissez la règle de comptage avant de comparer les propositions. Séparez au minimum le code source de production, le code généré, les dépendances tierces, les tests, le code de base de données, le contrôle des tâches, la configuration et les commentaires. Un million de lignes comprenant des stubs clients générés ne forme pas le même système qu'un million de lignes écrites à la main en COBOL, JCL, SQL et copybooks. Si l'estimateur refuse de montrer ces catégories, le total ne peut pas être audité.

Une simple commande d'inventaire fournit un premier contrôle aux responsables techniques. cloc n'est pas un outil d'estimation, mais il produit une structure stable que l'on peut recréer après une modification des exclusions :

cloc . --exclude-dir=vendor,node_modules,dist --by-file --json --out=cloc.json
jq '.SUM | {blank, comment, code}' cloc.json

Le résultat prend cette forme :

{"blank":18420,"comment":27116,"code":263904}

Conservez aussi la sortie par fichier. Elle permet à un relecteur de trouver les sous-systèmes concentrés, les blocs générés ayant échappé aux exclusions et les langages oubliés au premier passage. Pour un parc mainframe, comptez le JCL, les copybooks, les sorties assembleur, les procédures SQL, les cartes d'écran et les définitions du planificateur avec le langage applicatif. Ils contiennent parfois peu de logique métier, mais déterminent comment le système démarre, s'arrête, échange des fichiers et se rétablit.

Le nombre de lignes fonctionne surtout comme dénominateur. Les défauts par millier de lignes, les branches par module, les appels d'intégration par millier de lignes et les tests couvrant chaque capacité métier apportent tous une information. Un prix obtenu en multipliant les lignes par un tarif universel n'en apporte aucune. Une même ligne peut déclarer un champ, contenir un getter généré ou porter la branche qui décide si un compte reçoit des intérêts après un ajustement antidaté.

Les branchements mesurent le comportement à préserver

Les branchements comptent parce que chaque chemin de décision peut encoder un comportement observable distinct. Comptez les points de décision, mesurez leur combinaison et repérez où l'état ou les données externes modifient le résultat. Un module plat avec vingt validations indépendantes reste plus facile à comprendre qu'une routine où dix décisions s'imbriquent et partagent un état modifiable.

La complexité cyclomatique fournit un premier signal raisonnable. Thomas McCabe l'a définie à partir du graphe de flot de contrôle, souvent résumée pour une routine connectée par le nombre de décisions plus un. Ce nombre ne prédit pas seul l'effort. Il indique combien de chemins indépendants existent, tandis que l'imbrication révèle à quel point une personne ou un outil aura du mal à les suivre.

Le secteur confond régulièrement le nombre de branches et la profondeur des branchements. Prenons deux routines contenant chacune huit décisions. Dans la première, huit clauses de garde rejettent les enregistrements invalides, puis un calcul s'exécute. Dans la seconde, l'éligibilité, la juridiction, la catégorie de produit, la date d'effet, le statut d'exception et les ajustements précédents s'imbriquent sur six niveaux. Les deux peuvent recevoir un score cyclomatique voisin. La seconde demande généralement plus de fixtures, une reconstruction plus minutieuse de l'état et davantage de vérification, car chaque condition modifie le sens de toutes celles qui la suivent.

Demandez une distribution, pas une moyenne. Une moyenne sur tout le dépôt masque les cinq routines qui contrôlent les mouvements d'argent ou l'exploitation d'une usine. Les catégories utiles comprennent les routines au-dessus d'un seuil cyclomatique convenu, la profondeur d'imbrication maximale, le fan-in, le fan-out et le volume de code accessible depuis des points d'entrée aux conséquences fortes. Le seuil doit signaler un travail d'examen, pas déclarer que le code est "mauvais".

Demandez aussi si l'analyse résout la répartition dynamique, les appels générés, les macros et les règles pilotées par la base. L'analyse statique peut manquer un nom de programme lu dans une table, un CALL COBOL assemblé à l'exécution ou un événement de formulaire VB6 raccordé hors de la routine visible. Un rapport honnête marque les arêtes non résolues. Il ne traite pas discrètement les données manquantes du graphe comme une faible complexité.

La complexité modifie une estimation par le travail nécessaire pour produire les preuves. Chaque chemin important a besoin d'une entrée connue, d'une sortie attendue et d'un état initial pertinent. Si les traces de production couvrent la plupart des chemins, l'équipe peut tirer ses cas de la réalité. Si les journaux ne capturent qu'un code d'état final, quelqu'un doit reconstruire les décisions en lisant le code et en lançant des exécutions ciblées. Le travail diffère, même lorsque le code reste identique.

Les intégrations externes créent un risque aux frontières

Les intégrations externes méritent leur propre inventaire, car une réécriture échoue plus souvent aux frontières que sur la syntaxe. Une "intégration" dépasse largement l'API HTTP. Elle comprend les fichiers déposés dans un stockage partagé, les files de messages, les sessions de terminal, les liens de base de données, les flux d'impression, SMTP, les événements du planificateur, les commandes shell, les fournisseurs d'identité, les appareils matériels et les personnes qui déplacent manuellement des sorties entre les systèmes.

Comptez chaque contrat distinct, puis consignez sa direction, son protocole, son propriétaire, sa fréquence, son authentification, la forme des données, son comportement en cas d'échec et son substitut de test. Dix points de terminaison derrière un client de service documenté peuvent être plus simples qu'un seul fichier nocturne à largeur fixe dont le propriétaire est parti et dont les rejets arrivent dans la boîte mail d'un opérateur.

La question gênante consiste à savoir si une intégration peut être exercée hors production. Un bac à sable fournisseur avec des données artificielles peut ne pas reproduire la limitation de débit, l'ordre, le renouvellement des certificats ou la fin de journée. Une base partagée peut ne disposer d'aucune copie de test. Un partenaire peut n'accepter qu'une seule fenêtre de certification. Ces contraintes appartiennent à l'estimation, car elles déterminent la vitesse à laquelle l'équipe pourra vérifier que le remplacement est correct.

Inventoriez les deux côtés de chaque frontière. Appeler une API ne représente que la moitié du contrat. L'ancien système peut relancer selon certains codes, supprimer les doublons, dépendre de l'ordre des réponses ou écrire un enregistrement de rapprochement après un délai dépassé. Les interfaces par fichiers portent des règles comparables dans les noms, l'encodage, les fins de ligne, les bandes de contrôle, les fichiers vides, les livraisons partielles et les nouvelles exécutions. Réduire tout cela à "une intégration SFTP" élimine précisément les détails qui risquent le plus de bloquer la bascule.

La propriété constitue une donnée du calendrier, pas une note d'organisation. Identifiez qui peut répondre aux questions, délivrer des identifiants, approuver une règle de pare-feu, fournir un exemple et observer un test. Si aucun propriétaire n'existe, chiffrez explicitement la découverte et la marge. Ne cachez pas ce risque dans une réserve générale, car les responsables doivent pouvoir nommer un propriétaire avant de signer.

Une estimation crédible sépare l'implémentation de l'intégration et sa preuve. Écrire un nouveau client peut être banal. Prouver son bon comportement lors des relances, des entrées mal formées, des doublons, des livraisons tardives et des indisponibilités du partenaire concentre l'incertitude. Demandez les deux chiffres.

La surface de test fixe le niveau de confiance

La surface de test réunit les comportements observables que l'on peut provoquer et comparer, pas le nombre de fichiers de test dans le dépôt. Les tests unitaires existants n'aident que s'ils vérifient un comportement que le nouveau système doit préserver. Une suite remplie de mocks peut décrire l'ancienne structure de classes tout en disant peu de choses sur les factures, les écritures, les messages ou les fichiers à la frontière du système.

Mesurez cette surface par capacité métier et point d'observation. Pour chaque point d'entrée, indiquez quelles entrées peuvent être rejouées, quel état initial peut être recréé, quelles sorties peuvent être capturées et quels effets de bord peuvent être comparés. Incluez les réponses d'API, les mutations de la base, les messages sortants, les fichiers générés, les écritures comptables, les autorisations, les délais qui influent sur l'ordre et les erreurs visibles par les opérateurs.

Le trafic de production enregistré s'avère particulièrement utile, car il contient des combinaisons que personne n'a pensé à mettre dans un plan de test. Il exige tout de même des règles de traitement. Les secrets et les données personnelles peuvent devoir être masqués, les requêtes peuvent dépendre d'un état expiré et le rejeu d'une commande peut déclencher un effet externe. Une trace fournit une preuve, pas automatiquement une fixture sûre.

La couverture possède au moins trois sens dans une réécriture, et les propositions les échangent souvent sans prévenir. La couverture du code source demande quelles instructions ou branches anciennes ont été exécutées. La couverture des exigences demande quelles règles documentées ont des tests. La couverture du comportement demande quelles combinaisons d'entrées et de sorties visibles de l'extérieur ont été comparées. Une réécriture peut afficher une forte couverture du source tout en manquant une convention de fichier non documentée dont dépend l'exploitation. Pour la recette, la couverture du comportement pèse le plus lourd.

Demandez comment les écarts seront classés. Certaines différences sont des défauts. D'autres révèlent un ancien bug que l'entreprise souhaite conserver provisoirement. D'autres encore viennent des horodatages, des identifiants générés, de l'ordre, des arrondis, des paramètres régionaux ou de dépendances non déterministes et nécessitent une normalisation. Sans règle de comparaison convenue, un pourcentage de parité ne signifie rien, car une équipe peut l'améliorer en ignorant les champs difficiles.

L'estimation doit annoncer le niveau de preuve visé. Un outil interne de consultation à faible conséquence peut se contenter de cas représentatifs et d'une recette utilisateur. Un moteur d'écritures peut exiger le rejeu du trafic enregistré, des fixtures ciblant les branches, des totaux de rapprochement et une injection contrôlée de pannes. Le niveau de confiance recherché modifie le travail. "Réécrire le même code" ne définit pas cette cible.

La sémantique des données peut dépasser la taille de l'application

Le travail sur les données augmente avec leur sens, leur histoire et leur couplage, pas seulement avec le nombre de lignes. Une petite base peut contenir des colonnes surchargées, des codes implicites, des clés étrangères cassées, des règles temporelles et des procédures stockées qui portent l'essentiel du comportement. Une grande table d'événements en ajout seul peut se déplacer proprement parce que son contrat reste simple.

Estimez séparément la traduction du schéma, le nettoyage des données, l'exécution de la migration, le rapprochement et le retour arrière. Ce sont des tâches différentes. Traduire un champ décimal compacté vers un type numérique Postgres est mécanique. Décider si une valeur vide, zéro et une valeur sentinelle signifient toutes "inconnu" exige des preuves tirées du code et des données de production. Le rapprochement prouve ensuite que la correspondance choisie a préservé les soldes et les comptes.

L'état caché coûte particulièrement cher. Les programmes anciens communiquent souvent par tables de travail, enregistrements de contrôle, fichiers de séquence, variables d'environnement ou conventions de nommage plutôt que par appels explicites. Une tâche batch écrit un octet d'état, puis une tâche ultérieure l'interprète comme une autorisation de sauter un compte. Un diagramme de schéma ne montre pas ce comportement. L'analyse des dépendances doit inclure les lectures et écritures, l'ordre des tâches et la durée de vie des états intermédiaires.

Le volume compte toujours, mais demandez des distributions et des limites opérationnelles. Le pic des changements quotidiens, la plus grande partition, la largeur des enregistrements, la rétention, les arrivées tardives et l'interruption autorisée comptent davantage que le nombre total de lignes depuis l'origine. Une migration tenant dans une fenêtre de maintenance suit un autre plan qu'une migration exigeant une capture des changements et des rapprochements répétés pendant que les deux systèmes fonctionnent.

N'acceptez pas "migration de la base incluse" comme une mesure. Demandez quelles tables possèdent des correspondances source-cible, quels champs gardent un sens non résolu, quelles routines stockées passent dans des services, combien de règles de rapprochement existent et comment le retour arrière fonctionne après des écritures dans le nouveau système. Un estimateur incapable de répondre a chiffré une hypothèse.

Le code d'exploitation appartient au périmètre du système

Les planificateurs, les scripts de déploiement, les procédures opérateur, les règles d'accès, la supervision et les procédures de reprise font partie du comportement de l'application. Les laisser hors de l'estimation produit un remplacement qui réussit une démonstration, mais ne sait pas clôturer une journée d'activité.

Les parcs batch le montrent clairement. JCL ou CL peuvent définir les dépendances, l'exécution conditionnelle, l'allocation des jeux de données, les points de reprise et les notifications. Le source applicatif peut paraître simple alors que le réseau de tâches porte le véritable flot de contrôle. Sur les systèmes de bureau, les scripts d'installation, les paramètres du registre, les dossiers partagés et les tâches planifiées jouent le même rôle. Dans les monolithes web, les entrées cron et les actions manuelles d'administration comblent souvent les vides.

Demandez le nombre de tâches planifiées, de déclencheurs, d'unités de déploiement, de paramètres propres à chaque environnement, de rôles, d'alertes, de rapports et d'interventions opérateur documentées. Reliez-les ensuite aux capacités métier. Une liste sans graphe de dépendances ne peut montrer si une tâche en échec redémarre sans danger ou si un identifiant bloque quinze processus.

Le comportement de reprise exige des tests directs. Arrêtez un batch après l'écriture de la moitié de sa sortie. Livrez deux fois le même message. Faites expirer une dépendance après l'acceptation d'une requête. Restaurez un instantané de base avec du travail encore en attente. L'ancien système peut contenir des années de réponses pratiques à ces cas, même si personne ne les a écrites. La réécriture doit soit les préserver, soit les remplacer par des décisions approuvées par l'entreprise.

Ce domaine révèle aussi pourquoi une recommandation populaire est mauvaise : "moderniser l'exploitation après la parité fonctionnelle." Les équipes l'apprécient parce qu'elle semble réduire le périmètre. En réalité, elle repousse la découverte des exigences de redémarrage, d'ordre, d'accès et de supervision jusqu'à ce que la nouvelle conception soit figée. Les tableaux de bord cosmétiques peuvent attendre. Le comportement qui maintient l'argent, les enregistrements et les tâches cohérents après une panne ne le peut pas.

La préparation à l'exploitation doit apparaître comme un travail mesuré, avec des responsables et des preuves de recette. Si une proposition la réduit à une courte ligne près du déploiement, son prix reste incomplet.

Les changements d'architecture exigent deux estimations distinctes

Moderniser l'architecture et préserver le comportement forment deux chantiers liés, mais différents. Chiffrez-les séparément afin qu'un choix de conception ne réduise pas discrètement le niveau de preuve promis. Une frontière de service peut améliorer la propriété et le déploiement, tout en créant des contrats, des modes de panne et des décisions de cohérence des données que le monolithe gérait avec des appels locaux et une seule transaction.

Les estimations de translittération paraissent souvent bon marché, car elles associent une ancienne unité à une nouvelle. Cette méthode peut préserver une structure accidentelle, un état global et des contraintes de déploiement dépassées. Une réécriture sérieuse doit identifier les capacités et choisir des frontières adaptées à l'environnement cible. L'estimation doit inclure l'analyse nécessaire pour séparer ces capacités, pas seulement la production d'une syntaxe équivalente.

L'erreur opposée consiste à nourrir une ambition architecturale sans budget pour le comportement. Une proposition peut promettre des services, des événements, un nouveau client et une nouvelle base, tout en accordant peu de temps à la découverte du fonctionnement réel du système existant. L'équipe prendra des décisions de conception propres à partir d'un modèle incomplet. Le résultat pourra être séduisant sur un diagramme et faux lors d'un remboursement, d'une réexécution ou d'une panne partielle.

Demandez deux cartes reliées. La carte du comportement connecte les anciens points d'entrée, les décisions, les changements d'état et les sorties. La carte cible affecte ces comportements à de nouveaux composants et précise quel ancien couplage disparaîtra. Chaque responsabilité déplacée demande une preuve des deux côtés : ce qui établit l'ancien comportement et ce qui établit le nouveau contrat. Les responsables peuvent ainsi distinguer une modernisation délibérée d'une conversion de fichiers avec de nouveaux noms de répertoires.

Les comportements transversaux demandent une attention particulière pendant la décomposition. L'authentification, l'autorisation, la portée des transactions, l'idempotence, les arrondis, les paramètres régionaux, les traces d'audit et la traduction des erreurs peuvent apparaître dans beaucoup d'anciens modules en l'absence de frontière centrale. Compter chaque copie comme une fonction distincte gonfle l'estimation. Compter le sujet une seule fois en ignorant ses variantes observables la sous-estime. Mesurez les comportements distincts, puis concevez leur implémentation commune.

Les exigences de performance appartiennent à la même comparaison. Ne reproduisez pas chaque caractéristique temporelle accidentelle de l'ancien système, mais identifiez les délais qui ont un sens métier : une réponse terminal avant que l'opérateur ne relance, un batch terminé avant l'ouverture du marché suivant ou un export livré avant l'heure limite du partenaire. Consignez les distributions actuelles lorsque des preuves existent et définissez des limites cibles. Une vague promesse de vitesse supérieure ne permet aucune recette.

L'architecture modifie aussi le plan de bascule. Un remplacement en une fois exige une parité complète et un retour arrière crédible avant le déplacement du trafic. Un remplacement progressif exige des règles de routage, des flux de données de coexistence et la preuve que les composants anciens et nouveaux concordent pendant la transition. Aucune méthode n'est toujours moins chère. L'estimation doit montrer la mécanique temporaire nécessaire à chacune et la date à laquelle elle pourra être retirée.

Lorsque les relecteurs voient la préservation du comportement et la conception cible sur des lignes séparées, les arbitrages deviennent honnêtes. Ils peuvent simplifier une frontière cible sans prétendre qu'une ancienne règle a disparu, ou retirer une règle ancienne par une décision métier explicite. Un responsable technique a besoin de cette maîtrise avant d'accepter un chiffre fixe.

Un modèle pondéré rend les hypothèses visibles

Une bonne estimation de réécriture logicielle combine des dimensions mesurées et montre comment chacune influe sur l'effort. Elle n'a pas besoin d'une formule universelle. Elle a besoin d'un modèle que les relecteurs peuvent contester, mettre à jour et relier aux preuves.

Commencez par un tableau d'inventaire au niveau des sous-systèmes. Une ligne par unité déployable ou capacité métier cohérente apporte généralement plus qu'une ligne par dépôt. Utilisez des colonnes comme celles-ci :

Notez la confiance à côté de chaque mesure. "42 interfaces, 39 examinées, 3 déduites" apporte davantage que "42 interfaces." Indiquez la source de la preuve, telle qu'une analyse statique, une trace de production, un examen de configuration, un entretien ou des données d'exemple. Un élément déduit doit porter une réserve supérieure à un élément observé.

Présentez ensuite l'estimation sous forme de fourchettes par chantier. Un modèle interne simple pourrait ressembler à ceci :

replacement = source inventory adjusted for repetition and generated code
behavior proof = consequential paths x fixture cost x evidence gap
integration work = contract implementation + failure proof + owner delay risk
data work = mapping + transformation + rehearsal + reconciliation
operations = deployment + observability + recovery exercises

Ne transformez pas ce croquis en arithmétique factice. Les multiplicateurs doivent venir des travaux achevés par l'équipe de livraison et les unités nécessitent des définitions. Son but consiste à révéler pourquoi deux systèmes de taille voisine reçoivent des estimations différentes.

Les fourchettes doivent se resserrer avec l'amélioration des preuves. Avant l'accès au code, une proposition peut contenir des bornes larges et des hypothèses explicites. Après l'analyse du dépôt, l'échantillonnage du trafic et les entretiens sur les intégrations, le fournisseur doit remplacer les hypothèses par des comptes. Si le chiffre reste fixe alors que les preuves changent, l'estimation initiale constituait probablement un objectif commercial plutôt qu'un résultat technique.

CodeHero lit toute la base de code dans plusieurs langages et utilise le trafic de production enregistré dans un banc de parité. Son estimation peut donc relier la structure du source au comportement observable au lieu d'appliquer le même tarif à chaque ligne. Cela n'excuse pas des données d'entrée floues : les responsables techniques doivent demander ce qui a été compté, ce que représente le trafic et quelles frontières n'ont pas encore été prouvées.

L'échec d'une estimation sur un petit système

Prenons une application de tarification des sinistres de 38 000 lignes. Un devis basé sur les lignes la fait paraître modeste. Le dépôt contient un client de bureau, une bibliothèque de calcul, des procédures SQL et un export nocturne. Les tests existants couvrent la bibliothèque de calcul et l'équipe considère d'abord le reste comme de la plomberie ordinaire.

La découverte révèle quatre faits. Le client choisit les chemins de calcul en activant et désactivant des champs avant d'appeler la bibliothèque. Les règles de produit vivent dans six tables SQL maintenues par l'exploitation. L'export nocturne n'est accepté que si ses totaux de bande de contrôle correspondent au calcul indépendant d'un partenaire. Le recalcul d'un sinistre ancien dépend de la version de la table de règles qui était active à la date de service initiale.

Aucun de ces faits n'ajoute beaucoup de lignes source. Chacun agrandit le comportement à capturer. L'état du client devient un contrat d'entrée. Les tables de règles nécessitent des fixtures versionnées et des règles de migration. La logique de contrôle nécessite des exemples du partenaire et des tests de rejet. Le recalcul historique nécessite de reconstruire les données selon le temps.

Supposons maintenant que la suite actuelle exécute 85 pour cent de la bibliothèque de calcul. Le chiffre paraît rassurant, mais il ne couvre que le composant dont le client a déjà transformé les entrées. Un plan de parité doit capturer l'action de l'utilisateur, l'état du client, la version de règle choisie, les changements de base, le résultat du calcul et l'enregistrement d'export. La surface de test utile va d'un bout à l'autre, même si l'architecture cible sépare proprement ces responsabilités.

L'estimation change parce que l'unité de travail passe des lignes remplacées aux comportements prouvés. L'équipe peut toujours ne réécrire que 38 000 lignes. Elle doit aussi identifier les chemins de décision de l'interface, extraire l'historique des règles, émuler la validation du partenaire et comparer les sorties anciennes et nouvelles sur des cas enregistrés. Parler de dépassement serait malhonnête si le devis initial n'a jamais mesuré ces éléments.

Une réponse pratique existe lorsque la découverte révèle cette forme. Gelez le forfait jusqu'à ce que le fournisseur produise l'inventaire des frontières et le plan de parité. Tous les tests n'ont pas besoin d'être écrits avant la signature, mais il faut des comptes, des sources de preuve, des exclusions et une méthode pour transformer les inconnues en décisions. Sinon, le contrat transfère un risque impossible à connaître sur le papier et laisse les deux parties se battre plus tard.

Exiger le dossier de mesure avant de signer

Un responsable technique doit recevoir l'estimation et les preuves qui la soutiennent. Un total bien présenté sans dossier de mesure empêche l'examen technique et rend les disputes ultérieures sur le périmètre presque inévitables.

Le dossier doit répondre à un ensemble compact de questions :

1. Quelles catégories de source ont été comptées, lesquelles ont été exclues et pouvons-nous relancer l'inventaire ?
2. Où se trouvent les chemins de décision les plus profonds et les plus lourds de conséquences, y compris les appels dynamiques non résolus ?
3. Quels contrats externes existent, qui en est propriétaire et lesquels peuvent être testés hors production ?
4. Quels sens de données, migrations et règles de rapprochement restent non résolus ?
5. Quelles entrées peuvent être rejouées, quelles sorties peuvent être comparées et comment normalise-t-on les différences acceptables ?

Demandez les réponses par sous-système, avec des niveaux de confiance et des sources de preuve. Une moyenne à l'échelle du dépôt ne suffit pas. Une interface de règlement impossible à tester peut dominer le risque alors que cinquante modules ordinaires rendent la moyenne rassurante.

Les conditions commerciales doivent suivre les mesures. Un périmètre fixe convient lorsque les frontières et les preuves de recette sont connues. Une phase de découverte payante peut se justifier en l'absence d'accès, de propriétaires ou de traces de production, mais elle doit produire des artefacts réutilisables plutôt qu'un jeu de diapositives : inventaires, graphes, correspondances, échantillons et fourchette mise à jour. La réserve doit être attachée à des inconnues nommées et diminuer lorsque le client les résout.

Refusez les estimations qui affichent une précision sans exclusions. Refusez aussi le mouvement inverse, lorsque le fournisseur qualifie tout d'incertain et réclame un temps illimité. Une bonne estimation réduit l'incertitude par l'examen du code, le suivi du comportement et les tests aux frontières. Elle montre les inconnues restantes et la personne capable de les éliminer.

CodeHero s'engage à livrer en moins de 30 jours. La mesure précoce du code, du comportement, des intégrations, des données et de l'exploitation devient donc obligatoire. Quel que soit le fournisseur envisagé, exigez que l'estimation nomme le système testable qu'il compte livrer. Un total de lignes décrit les matériaux posés au sol. Le dossier de mesure décrit le bâtiment dont il doit achever la construction.