Audit technique : les signaux d’alerte qui comptent

Tous les signaux d’alerte d’une due diligence technique ne se valent pas. Une version de framework en retard de deux ans fait mauvais effet dans un rapport et ne coûte presque rien. Un système que seul le fondateur sait faire tourner ne choque personne en réunion et peut vider le deal de sa substance. Le travail de l’auditeur n’est pas de dresser la liste des défauts ; c’est de dire lesquels changent le prix, lesquels changent le contrat, et lesquels ne changent rien.

Voici comment nous faisons ce tri, à partir de ce que nous observons réellement dans les audits.

Les signaux d’alerte sérieux dans une due diligence technique

Le premier de la liste : l’absence de tests combinée à l’absence de revue de code. Chacun des deux, isolé, se rencontre dans des équipes saines ; un produit jeune peut avoir peu de tests si chaque changement passe par une relecture rigoureuse. Les deux ensemble signifient qu’aucun mécanisme ne protège la base de code, et que la vélocité affichée est empruntée au futur. C’est le cœur de la dette qui se chiffre, et elle se négocie.

Viennent ensuite les secrets dans le code : clés d’API, mots de passe, jetons d’accès committés dans l’historique. Au-delà du risque direct, c’est un révélateur de culture : une équipe qui committe ses secrets n’a probablement ni gestion des accès ni hygiène de sécurité ailleurs.

Le système à une personne, ensuite. Quand une seule personne peut déployer, déboguer la production et expliquer le pipeline de données, vous n’évaluez plus un actif technologique, vous évaluez la loyauté d’un individu. Ce risque homme-clé est le signal le plus fréquent dans les cibles de moins de trente personnes, et le plus sous-estimé par les acquéreurs.

Enfin, les métriques invérifiables. Quand les chiffres d’usage du pitch ne se retrouvent ni dans les logs ni dans la base de données, il y a deux explications possibles, et aucune n’est bonne. Un écart de ce type a déjà transformé, sous nos yeux, une phase confirmatoire en retrait d’offre. C’est le seul signal de cette liste qui touche à la confiance plutôt qu’à la technique, et c’est pour cela qu’il est le plus grave.

Le cosmétique qui fait peur pour rien

À l’inverse, une partie des observations qui noircissent les rapports d’audit classiques ne mérite pas une ligne de négociation. Des versions de frameworks en retard, tant que les correctifs de sécurité suivent. Du code inélégant dans des modules périphériques. Une documentation interne mince, si le savoir est réparti sur plusieurs têtes. Un monolithe au lieu de microservices : à taille égale, c’est souvent le choix le plus raisonnable, pas un défaut. De la dette technique assumée et documentée par l’équipe, qui est un signe de maturité, pas de négligence.

Le test que nous appliquons : ce défaut change-t-il le coût de possession, le risque d’exploitation ou la capacité à exécuter la roadmap financée. Si la réponse est non aux trois, le défaut va dans l’annexe, pas dans la synthèse.

Classer par sévérité

Notre registre des risques classe chaque signal sur deux axes : l’impact s’il se matérialise (en euros, en mois de roadmap ou en risque réglementaire) et le coût de remédiation. Ce classement produit quatre familles utiles à la décision. Les risques graves et coûteux à corriger sont les vrais sujets de négociation. Les risques graves mais corrigeables à coût raisonnable deviennent des conditions ou des engagements post-closing. Les risques modérés alimentent le plan des cent jours. Le reste documente.

Ce classement est ce qui distingue un audit d’un scan. Un outil détecte des occurrences ; il faut avoir exploité des systèmes en production pour dire qu’un secret dans un repo privé avec dix accès ne pèse pas comme le même secret dans un repo accessible à un prestataire parti fâché. Le contexte fait la sévérité, et le contexte se collecte surtout en parlant aux gens, notamment pendant l’entretien avec le CTO.

Renégocier ou renoncer

La plupart des signaux sérieux ne tuent pas un deal, ils le reprisent. Une dette lourde mais cartographiée se traduit en ajustement de prix ou en enveloppe de remédiation sanctuarisée. Un risque homme-clé se traduit en clauses de rétention et en plan de transfert de savoir. Des lacunes de sécurité se traduisent en conditions suspensives avec un calendrier.

Nous ne recommandons de renoncer que dans deux cas. Quand les métriques présentées se révèlent invérifiables ou contredites par les données, parce qu’aucune clause ne répare une confiance rompue avant la signature. Et quand le cumul des remédiations absorbe le plan de création de valeur : si les deux premières années servent à réparer au lieu de construire, la thèse d’investissement n’existe plus, quel que soit le prix.

Le tri entre ces cas demande de voir beaucoup de systèmes, et de savoir ce qui se répare vraiment en trois mois. C’est ce regard que nous apportons avec notre audit technique, en phase confirmatoire comme en amont d’une offre.