La due diligence technique change le prix

La due diligence technique n'est pas un concours de qualité du code. Un acheteur veut savoir quels faits techniques changent les flux de trésorerie futurs, menacent la propriété de l'actif, retardent l'intégration ou rendent l'entreprise dépendante d'une personne susceptible de partir après la signature. Des abstractions propres sont agréables. Des livraisons prévisibles, des droits démontrables et un risque opérationnel maîtrisé influent sur l'opération.

J'ai vu des acheteurs débattre pendant des jours de conventions de nommage alors qu'un traitement nocturne de règlement n'avait ni responsable, ni build reproductible, ni test capable de prouver que le résultat d'hier correspondait à celui d'aujourd'hui. C'est prendre le problème à l'envers. Un examen utile suit les conséquences commerciales dans le code, le circuit de déploiement, les personnes et les contrats, puis indique l'effet de chaque constat sur le prix ou les conditions.

L'acheteur chiffre l'incertitude, pas le style

L'acheteur utilise la due diligence technique pour transformer les inconnues en plan chiffré. La base de code fournit des preuves, mais elle n'en est qu'une partie. L'historique des dépôts, les systèmes de build, la télémétrie de production, les comptes rendus d'incidents, les manifestes de dépendances, les schémas d'architecture, les contrôles d'accès et les entretiens montrent si le logiciel pourra continuer à générer du revenu sous un nouveau propriétaire.

La première distinction souvent brouillée sépare le défaut du risque transactionnel. Une requête lente avec une correction claire, un responsable et un rayon d'impact limité est un défaut. Un moteur de facturation non documenté que seul un prestataire comprend est un risque transactionnel, même s'il fonctionne sans incident depuis des années. Le premier crée un ticket d'ingénierie. Le second peut justifier une retenue, une condition de réalisation, un accord de transition ou une valorisation plus faible, car la probabilité de panne et le coût de reprise restent difficiles à borner.

Les auditeurs doivent relier chaque constat important à un mécanisme économique. Exige-t-il une correction immédiate ? Bloque-t-il un rapprochement de produits prévu ? Peut-il interrompre le chiffre d'affaires, enfreindre un contrat client ou empêcher l'acheteur d'exploiter l'actif ? Faut-il retenir un salarié précis ou acheter une licence commerciale ? Sans ce lien, un constat reste une observation, pas un résultat de diligence.

Les niveaux de sévérité masquent cette logique. Deux constats marqués « élevé » peuvent avoir des effets différents. Un endpoint d'administration public peut exiger une action avant la réalisation. Une base de données proche de sa capacité peut justifier un projet financé après l'acquisition. Une contribution au code contestée peut nécessiter une indemnisation. Décrivez la conséquence et le contrôle disponible avant de choisir une couleur.

L'acheteur a aussi besoin d'un niveau de confiance. Si les auditeurs ne peuvent pas exécuter le système, accéder à des données proches de la production ou interroger l'opérateur, ils ne doivent pas déclarer discrètement la zone saine. Ils doivent consigner l'absence de preuve comme un risque distinct. Une preuve manquante modifie souvent les conditions plus qu'un défaut connu, car personne ne peut honnêtement chiffrer sa limite haute.

L'accès aux dépôts doit prouver ce qui est acheté

L'accès aux dépôts doit établir l'exhaustivité, l'historique et la provenance avant tout examen de l'architecture. Un dépôt applicatif bien présenté peut détourner l'attention de scripts de déploiement manquants, de générateurs de rapports, de micrologiciels, de tâches de base de données ou d'un répertoire copié manuellement sur les serveurs de production. La transaction porte sur un système en fonctionnement au sens large, pas sur le premier dépôt ouvert par le vendeur.

Demandez un inventaire qui associe chaque composant de production à un dépôt, un chemin de build, un responsable du déploiement, un runtime, un stockage de données et un environnement. Rapprochez cet inventaire des comptes cloud, planificateurs, registres de paquets, systèmes de fichiers des serveurs, boutiques mobiles, enregistrements DNS et factures fournisseurs. Si un exécutable génère du revenu sans emplacement source, l'acheteur acquiert peut-être un binaire qu'il ne peut pas reproduire.

L'historique compte, car un instantané actuel ne révèle ni la paternité ni la concentration du développement. Obtenez tout l'historique des commits, les tags, les branches nécessaires aux versions maintenues, les sous-modules, le stockage des fichiers volumineux et les artefacts de build non reproductibles. Vérifiez si un import de dernière minute a aplati des années d'historique. Cela peut être innocent, mais empêche une analyse fiable des contributeurs et complique la vérification des déclarations de propriété intellectuelle.

Une courte séquence de triage donne une première carte utile. Exécutez-la sur une copie isolée, relisez chaque commande avant son lancement et adaptez les chemins au dépôt :

git rev-parse --is-shallow-repository
git shortlog -sne --all
git log --all --format='%aN <%aE>' | sort | uniq -c | sort -nr | head -20
git ls-files | sed 's|/.*||' | sort | uniq -c | sort -nr | head -30
find . -maxdepth 4 -type f \( -name 'package-lock.json' -o -name 'go.sum' -o -name 'Cargo.lock' -o -name 'pom.xml' -o -name '*.csproj' \) -print
find . -maxdepth 4 -type f \( -iname 'license*' -o -iname 'notice*' -o -iname 'copying*' \) -print

Le résultat attendu n'est pas une réussite ou un échec. C'est un ensemble de pistes : profondeur de l'historique, identités qui dominent les commits, emplacement des ensembles de sources, écosystèmes de dépendances présents et emplacement des mentions de licence. Il faut ensuite regrouper les alias et exclure les robots. N'assimilez jamais le nombre de commits à la propriété ou à la compétence. Les changements générés, imports, travaux en binôme et rebases le faussent.

Enfin, reproduisez une version maintenue depuis un commit documenté. Consignez la chaîne d'outils, les secrets nécessaires, les artefacts externes, la durée du build et les sommes de contrôle obtenues lorsqu'un résultat déterministe est attendu. Un build qui ne réussit que sur le portable d'un salarié n'est pas reproductible au seul motif que ce portable est disponible pendant l'audit.

Le risque de personne clé se cache dans les décisions et l'exploitation

Le risque de personne clé existe lorsque l'absence d'une personne peut arrêter une modification importante, une reprise ou un processus métier. La concentration des commits est un indice, pas un diagnostic. Le risque se cache dans les décisions non documentées, les identifiants privés, les rituels manuels de production, les relations fournisseurs, les corrections de données et le pouvoir d'approuver une mise en production.

Commencez par les parcours essentiels : prise de commande, règlement, facturation, clôture mensuelle, déclarations réglementaires, exécution et accès client. Pour chacun, demandez qui peut l'expliquer, le modifier, le déployer et le rétablir. Quatre noms ne valent mieux qu'un que si ces personnes peuvent agir indépendamment. Une équipe qui appelle toujours l'ancien fondateur avant de toucher une règle tarifaire n'a encore qu'un seul responsable effectif.

Testez les connaissances par le travail, pas seulement par des entretiens. Demandez à un deuxième ingénieur de suivre une transaction de production, de trouver la règle applicable, d'effectuer une modification sans danger hors production, de lancer les tests concernés et de décrire le retour arrière. Demandez à la personne d'astreinte de secours de restaurer une sauvegarde représentative et de diagnostiquer l'échec d'une tâche planifiée. L'observateur doit noter chaque besoin d'information non documentée ou d'autorisation d'un autre salarié.

Le cas délicat est celui d'un fondateur compétent qui prévoit de partir. Les acheteurs acceptent parfois une vague promesse de disponibilité parce que remplacer un savoir profond paraît gênant ou coûteux. Cette promesse est faible. Définissez un livrable de transition : runbooks nommés, visites guidées enregistrées, transfert des identifiants, mises en production en binôme, exercice d'incident et validation par les futurs opérateurs. Quand la dépendance est importante, liez l'achèvement à une condition de réalisation, un contrat de conseil ou un dispositif de rétention.

Ne confondez pas technologie ancienne et dépendance à un seul expert. Un parc COBOL bien géré avec plusieurs opérateurs, un comportement de production enregistré, des builds automatisés et une reprise répétée peut être plus sûr qu'un service à la mode écrit l'an dernier par un prestataire désormais parti. L'âge de la technologie influe sur le recrutement et le coût des changements. La concentration des connaissances influe sur la continuité. Les deux se rencontrent parfois, mais les preuves et les remèdes diffèrent.

Le prix change lorsque l'acheteur doit financer des doublons de personnel, retenir quelqu'un à des conditions exceptionnelles, repousser l'intégration ou accepter un risque d'interruption impossible à assurer. Si un transfert de connaissances pratique peut combler l'écart avant la réalisation, faites-en une condition. Si le vendeur ne peut pas transférer ce savoir parce que personne ne l'a encore, traitez la correction dans le dossier d'investissement, pas comme une tâche documentaire.

L'exposition aux licences commence par la provenance

L'examen des licences doit déterminer si le vendeur a le droit de transférer et d'exploiter chaque partie importante du produit. Un scanner de dépendances aide, mais ne prouve ni la cession des salariés, ni les droits des prestataires, ni l'origine de fragments copiés, ni les droits sur les composants achetés ou les données d'entraînement, ni les conditions attachées au code reçu d'un partenaire. Ce sont des questions de provenance.

Créez une nomenclature logicielle à partir des manifestes, fichiers de verrouillage, répertoires de fournisseurs intégrés, images de conteneurs, clients générés, paquets mobiles et paquets de système d'exploitation livrés avec le produit. Rapprochez-la de ce qui arrive vraiment aux clients ou en production. La documentation du graphe de dépendances de GitHub indique que son analyse statique lit les manifestes et fichiers de verrouillage pris en charge. Cette limite compte : un ancien fichier JavaScript collé dans un répertoire fournisseur ou un binaire placé dans un dossier de version peut rester hors du graphe.

Utilisez les identifiants SPDX pour normaliser les constats. La spécification SPDX autorise des expressions avec AND, OR et WITH, conservant des distinctions qu'une colonne de tableur appelée « licence » détruit. GPL-2.0-only OR MIT offre un choix ; LGPL-2.1-only AND BSD-2-Clause indique que les deux s'appliquent à l'ensemble de paquets décrit. Un auditeur qui réduit les deux à une liste de noms peut recommander le mauvais remède.

Le scan produit des allégations à trancher. Pour chaque résultat important, consignez le composant et sa version, sa voie d'entrée dans le produit, ses modifications, son lieu de distribution ou d'hébergement, la licence détectée et celle retenue, les mentions ou offres de source requises, le responsable et les preuves. Les juristes interprètent le droit. L'ingénierie prouve l'utilisation et la possibilité de remplacement. Aucun métier ne peut finir seul.

Accordez la même attention à la propriété du code interne. Rapprochez les contributeurs des dates d'emploi, accords de cession d'invention, cahiers des charges des prestataires, annexes d'acquisition et apports provenant d'entreprises antérieures. Examinez les commits associés à des adresses personnelles, domaines externes, stagiaires, agences et fondateurs avant la constitution. Une garantie signée dans le contrat d'achat est utile, mais ne fait pas disparaître la revendication d'un tiers.

Le prix change lorsqu'un composant ne peut être légalement livré selon le modèle prévu, que son remplacement retarde le plan ou que la propriété reste contestable. Des lacunes mineures trouvent souvent leur place dans un calendrier de réalisation, une correction des mentions, une indemnité ciblée ou un séquestre. Ne déclarez pas toute dépendance copyleft fatale. La distribution, l'édition de liens, la modification et le texte réel de la licence déterminent les obligations. Les étiquettes générales ne remplacent pas l'analyse d'un juriste.

Une suite de tests ne prouve rien si elle ne peut pas échouer

L'état de la suite de tests compte parce que l'acheteur modifiera le système après la réalisation. Le nombre de fichiers et les pourcentages de couverture disent peu sur la détection des régressions métier. Mille assertions autour de l'accès aux données ne protègent pas un calcul de règlement dont personne n'a encodé le résultat attendu.

Exécutez la suite depuis un environnement propre avec la commande documentée. Notez le temps de préparation, les services externes, le traitement des secrets, la durée, les relances instables, les tests ignorés et les échecs sur la branche par défaut. Introduisez ensuite un petit défaut contrôlé dans une règle importante et vérifiez qu'un test pertinent échoue pour la bonne raison. Annulez immédiatement la modification. Cette mutation apprend souvent plus qu'un rapport de couverture parce qu'elle teste la capacité du test à s'opposer.

Séparez quatre formes de preuve. Les tests unitaires protègent les règles locales. Les tests d'intégration prouvent l'accord des composants sur les protocoles et la persistance. Les tests de bout en bout exercent les parcours déployés, mais peu de variantes. Les tests de comparaison ou de rejeu de production montrent si un remplacement préserve le comportement observé. Aucun ne remplace les autres. Une suite de navigateur verte ne valide pas un calcul de fin d'exercice, et une forte couverture unitaire ne prouve pas le bon fonctionnement des migrations de base.

Lisez l'historique des échecs de l'intégration continue. Une branche par défaut rouge que tous ignorent révèle un défaut de contrôle, même si chaque échec a une explication. Il en va de même d'une suite qui ne passe qu'après plusieurs tentatives. Demandez comment l'équipe isole les tests instables, qui peut contourner les contrôles, si les branches protégées exigent les résultats et en quoi les correctifs urgents diffèrent du chemin normal.

Les données de test créent leur propre risque. Déterminez si les fixtures contiennent des données de clients ou de salariés, comment elles sont masquées, qui y accède et si les obligations de suppression atteignent sauvegardes et copies de développeurs. L'acheteur ne veut pas découvrir pendant l'intégration que l'environnement de test le plus rapide dépend d'une copie de production sans contrôle.

Traduisez le résultat en coût du changement. Des tests faibles imposent des livraisons plus lentes, davantage de vérifications manuelles, plus d'incidents ou un investissement précoce dans des tests de caractérisation. Si la feuille de route prévoit une intégration rapide ou une réécriture de plateforme, l'absence de preuve comportementale peut modifier le prix, car l'acheteur ne dispose d'aucun moyen peu coûteux de prouver que le logiciel modifié produit encore les mêmes résultats.

L'exploitabilité révèle la facture d'ingénierie cachée

L'exploitabilité montre la quantité de travail consommée par le logiciel après son déploiement. Les acheteurs doivent examiner les mises en production, l'observabilité, la restauration des sauvegardes, la gestion des incidents, la capacité et les réparations courantes de données. Un produit peut sembler stable parce que deux personnes expérimentées empêchent discrètement des pannes visibles chaque jour. Leur travail appartient au modèle de coûts.

Observez une mise en production normale et, si le calendrier le permet, un retour arrière d'urgence. Repérez les contrôles manuels, comptes partagés, commandes non documentées, serveurs mutables et validations qui n'existent que dans une messagerie. Confirmez que la version déployée remonte à sa source et que l'équipe sait quelles migrations de base ont été appliquées. Un document de livraison décrivant le chemin idéal plutôt que la pratique est décoratif.

Demandez les dossiers d'incident et des exemples d'alertes, puis suivez un problème récent depuis sa détection jusqu'à sa correction en passant par le diagnostic. Les preuves utiles comprennent horodatages, attribution des alertes, journaux, métriques, communication client, travaux de suivi et preuve du passage de la correction en production. Une absence d'incidents enregistrés peut indiquer une excellente fiabilité. Elle peut aussi indiquer que l'entreprise ne les consigne pas. La télémétrie et les entretiens distinguent les cas.

Les sauvegardes méritent un test de restauration. Une capture d'écran de sauvegardes planifiées prouve l'exécution d'une tâche, pas la capacité de reprise de l'entreprise. Restaurez des données représentatives dans un environnement isolé, contrôlez l'intégrité, mesurez la procédure et identifiez les identifiants ou accès fournisseur nécessaires pendant une vraie panne. Comparez le résultat aux promesses faites aux clients et aux objectifs internes sans inventer une précision jamais mesurée.

Les corrections manuelles de données sont un autre angle mort. Cherchez dans les tickets, scripts, notebooks et historiques shell les ajustements de soldes, commandes, autorisations ou rapports. Déterminez qui les approuve, si les changements sont journalisés et si le défaut d'origine persiste. Des corrections fréquentes et sûres peuvent relever de l'exploitation. Des écritures non contrôlées en production créent une exposition financière et d'audit.

Ce travail modifie le prix lorsque du travail récurrent manquait dans le récit de marge du vendeur, que des travaux de capacité doivent précéder la croissance, que la reprise ne respecte pas les engagements contractuels ou que l'intégration retire une dépendance supposée par le système. Il modifie les conditions si le vendeur peut mener un exercice de restauration, transférer des comptes ou corriger un contrôle de livraison dangereux avant la réalisation.

L'architecture compte lorsqu'elle contraint la thèse du deal

L'examen de l'architecture doit tester l'usage prévu par l'acheteur, pas récompenser des diagrammes à la mode. Un monolithe peut être une bonne acquisition s'il se déploie de façon prévisible et soutient le plan de croissance. Un ensemble de services peut devenir un passif si la responsabilité reste floue, les appels forment des cycles et chaque livraison exige des changements coordonnés.

Associez les capacités métier aux modules, stockages, files, interfaces externes et unités de déploiement. Posez ensuite la thèse de l'opération sur cette carte. Si l'acheteur prévoit de fusionner l'identité client, le système sépare-t-il les locataires et rapproche-t-il les identités ? Pour une expansion internationale, où résident les hypothèses de devise, fiscalité, fuseau horaire et localisation des données ? Si les économies dépendent d'une consolidation de l'infrastructure, quels services propriétaires ou limites réseau y résistent ?

Cherchez des contraintes étayées : runtimes non maintenus, avis de fin de vie fournisseur, tables sans borne, appels synchrones dans les parcours de revenu, propriété partagée de bases, hypothèses d'environnement codées en dur et fenêtres batch proches de leur limite. Ne transformez pas automatiquement l'âge en gravité. Un ancien runtime derrière une interface stable peut avoir un remplacement borné. Un framework récent aux dépendances abandonnées peut être plus difficile à exploiter.

Les données sont souvent la partie difficile de l'intégration. Examinez propriété des schémas, historique de migration, conservation, identifiants, traitement des doublons, pistes d'audit et tâches de rapprochement. Demandez comment l'équipe répare les échecs partiels et signale les corrections aux consommateurs en aval. Si deux produits emploient le même mot pour des entités différentes, une passerelle API ne résout pas le conflit sémantique.

Estimez le changement par tranches de comportement observable, pas par lignes de code. Prenez un parcours métier représentatif, listez entrées, sorties et dépendances, puis demandez à l'équipe comment elle le déplacerait ou le remplacerait. La réponse révèle si les frontières existent en pratique. Elle expose aussi le travail caché dans les procédures stockées, clients de bureau, feuilles de calcul et tâches planifiées souvent absents des diagrammes.

Une estimation de réécriture n'est pas automatiquement une décote. Elle le devient quand le rendement de l'acheteur dépend de cette réécriture, que le système bloque un autre changement nécessaire ou que sa conservation impose un coût omis de la valorisation. Sinon, un système démodé mais contrôlé mérite un budget de modernisation planifié plutôt qu'une décote de panique.

Un constat de sécurité exige une voie d'exploitation et un remède

Les constats de sécurité influent sur une transaction lorsqu'ils créent une voie plausible vers un dommage important ou révèlent un contrôle manquant que l'acheteur devra fournir. Le score de sévérité d'un scanner n'est qu'un point de départ. L'exposition, les privilèges, les données accessibles, les mesures existantes, les prérequis d'exploitation et la détection déterminent le risque métier.

Suivez l'identité depuis la connexion client jusqu'aux accès d'administration et identifiants machine. Examinez cycle de vie des comptes, rôles privilégiés, application de l'authentification multifacteur lorsqu'elle est disponible, propriété des comptes de service, stockage des secrets et accès d'urgence. Échantillonnez des comptes réels au lieu d'accepter une politique. D'anciens salariés avec des identifiants actifs et des mots de passe administrateur partagés sont des faits ; une formule générale sur une mauvaise gestion des accès ne l'est pas.

Pour les vulnérabilités, prouvez que le composant touché est déployé et atteignable. Consignez version, chemin d'appel, contrôle des entrées, frontière de privilège, données exposées, mesure compensatoire et voie de mise à niveau ou retrait. Une dépendance vulnérable dans un outil de test ne se traite pas comme la même bibliothèque exposée sur un service public. Les deux demandent une décision, mais seules les preuves fixent la priorité.

Examinez comment l'entreprise reçoit, trie, corrige et divulgue les signalements. Inspectez des correctifs récents et leur chemin du rapport à la mise en production. En cas d'incident de sécurité, rapprochez les traces techniques des notifications clients, déclarations d'assurance, échanges réglementaires et informations données pour l'opération. Une incohérence peut compter davantage que la faille initiale car elle remet en cause les déclarations de la direction.

Les clients réglementés ajoutent des exigences, mais prendre en charge un environnement réglementé n'est pas détenir une certification. Demandez le contrôle contractuel exact, la frontière du système, la preuve et la partie responsable. Ne transformez pas un choix d'hébergement ou un rapport de test d'intrusion en vaste déclaration de conformité. L'acheteur hérite des promesses contractuelles signées, pas des adjectifs d'une présentation commerciale.

Une compromission immédiate, des incidents non divulgués ou des défaillances systémiques d'accès peuvent bloquer la réalisation. Les vulnérabilités corrigeables appartiennent généralement à un calendrier avec responsable et preuve. Cette distinction conserve la crédibilité du rapport : si chaque paquet obsolète menace l'opération, les décideurs n'écouteront plus lorsqu'un constat devrait réellement le faire.

Quelques mécanismes relient les constats au prix

Un problème technique change l'économie par son coût de correction, un bénéfice retardé, un coût récurrent, du revenu perdu ou interrompu, un passif éventuel ou une probabilité plus forte d'échec de la thèse. Les auditeurs doivent éviter la fausse précision, mais montrer le mécanisme et les hypothèses.

Utilisez une fiche de décision pour chaque constat important. Voici la forme minimale que j'attends :

Finding: Settlement rules have one effective owner
Evidence: Only one engineer can trace, change, deploy, and recover the nightly job
Business path: Customer settlement and finance reconciliation
Deal effect: Integration cannot safely begin on the planned date
Control before close: Backup owner completes a change and recovery exercise
Residual action: Add characterization tests around recorded settlement cases
Owner and evidence date: [named person] / [date]
Term response: Closing condition or funded retention agreement
Price response: Cost only if the control cannot be completed
Confidence: Medium, recovery was observed but a live release was not

Cette fiche sépare le fait de sa réponse. Elle évite aussi le double comptage. Si le modèle de valorisation comprend déjà un programme de modernisation, les auditeurs ne doivent pas déduire à nouveau le même travail sauf si l'examen étend sa portée ou son risque. Si un dispositif de rétention contrôle la dépendance à un expert, ne chiffrez pas en plus le scénario de panne complet comme certain. Montrez le risque résiduel après contrôle.

Des mécanismes différents appellent des outils transactionnels différents. Une correction connue et bornée peut réduire le prix ou augmenter le budget de l'acheteur. Un fait que le vendeur peut corriger peut devenir une condition de réalisation. Un risque précis de propriété ou de divulgation peut exiger déclaration, indemnisation, séquestre ou retenue conçue par les juristes. Un investissement futur incertain peut affecter les critères d'un complément de prix ou la thèse d'investissement, même si un complément mal conçu crée ses propres incitations.

Classez les constats selon la décision, pas selon le score du scanner. Le conseil doit savoir ce qui empêche la signature, ce qui doit arriver avant la réalisation, ce qui change la valeur, ce qui entre dans le premier plan d'exploitation et ce que l'acheteur accepte. Le détail d'ingénierie reste disponible en dessous, mais un catalogue de cent pages ne remplace pas ces choix.

La qualité des preuves mérite sa propre conclusion

Le rapport doit dire ce que les auditeurs ont observé, reçu et reproduit, ainsi que ce qui est resté inaccessible. La qualité des preuves contrôle la confiance dans chaque conclusion technique. Un schéma fourni par le vendeur et un déploiement observé ne méritent pas le même poids.

Utilisez des étiquettes simples : reproduit, observé, documenté, déclaré et indisponible. Reproduit signifie que l'auditeur a exécuté la procédure et obtenu le résultat. Observé signifie que l'équipe l'a effectuée sous ses yeux. Documenté signifie qu'un artefact soutient l'affirmation. Déclaré signifie qu'une personne l'a affirmée. Ces étiquettes n'accusent pas le vendeur de malhonnêteté ; elles montrent l'incertitude restante.

L'échantillonnage a aussi besoin de limites. Si les auditeurs inspectent trois services sur quarante, expliquez leur choix et les risques non couverts. Choisissez d'abord les parcours de revenu, composants privilégiés, changements récents et zones connues pour leurs problèmes, avant les dépôts bien rangés. Le hasard peut compléter le jugement, mais il manque souvent les systèmes capables d'endommager l'opération.

Les restrictions d'accès sont des constats lorsqu'elles empêchent une conclusion importante. Une base de production peut légitimement rester interdite, mais le vendeur peut souvent fournir des exports de schéma, échantillons masqués, plans de requêtes, trafic enregistré ou une session observée. Sans substitut, consignez la question non résolue et son effet possible. Ne transformez pas « non testé » en « aucun problème trouvé ».

La restitution finale doit être compréhensible par l'ingénierie, les finances, les juristes et le responsable du deal. Chaque public a besoin des mêmes faits à une résolution différente. Conservez une seule source pour preuves et décisions afin qu'une modification tardive ne laisse pas des diapositives, tableaux et annexes juridiques contradictoires.

Le premier plan d'exploitation commence avant la signature

Une bonne due diligence technique laisse à l'acheteur un plan de prise en charge exécutable, même si l'opération échoue. Le résultat le plus utile est une courte liste de décisions maîtrisées : quel risque change les conditions, quelle preuve manque, qui porte chaque action avant réalisation et quels travaux entrent dans le plan financé après celle-ci.

Ordonnez le travail selon dépendances et conséquences. Sécurisez l'accès administratif avant de changer le déploiement. Capturez le comportement de production avant de remplacer des règles. Transférez les connaissances fournisseurs et opérateurs avant l'expiration des préavis. Répétez la restauration avant de consolider l'infrastructure. Ce sont des contrôles précis, pas un backlog générique.

Le code ancien concentre souvent plusieurs risques : connaissances rares, tests faibles, provenance mixte et comportement réparti entre traitements batch, procédures stockées, code de bureau et feuilles de calcul. CodeHero traite ce cas précis en lisant toute la base de code, en réécrivant l'architecture en Go, Rust, TypeScript et Postgres lorsque cela convient, puis en vérifiant la parité avec le trafic de production enregistré, avec une livraison en moins de 30 jours. Cela peut changer l'option de correction, mais l'acheteur a toujours besoin d'une propriété nette, de preuves fiables et du droit d'exploiter le système.

Ne terminez pas le rapport sur une moyenne de risque. Nommez la condition dans laquelle l'opération fonctionne encore. Si l'acheteur peut maîtriser le circuit de livraison, retenir ou transmettre les connaissances critiques, régler les exceptions de licence et mesurer la parité de comportement, le risque d'ingénierie a des limites. Si ces conditions ne peuvent pas être réunies, le prix doit porter l'incertitude au lieu de demander à l'équipe d'intégration de la découvrir après les signatures.