Note
Les red flags d’une due diligence technique
La plupart des listes de red flags énumèrent des défauts. Un défaut se chiffre, se négocie, se déduit du prix. Un red flag dit tout autre chose : que ce qu’on vous montre ne recouvre pas ce qui existe.
Par Jonathan Brossard · Mis à jour le
I. Un red flag n’est pas un défaut
Le mot n’a pas le même sens des deux côtés de la table. Dans un fonds, un red flag report désigne un format de mission court, une à deux semaines, concentré sur ce qui peut faire échouer l’opération. Côté technique, on entend plutôt une liste de signaux d’alerte. Au fond, les deux disent la même chose : on ne cherche pas l’exhaustivité, on cherche ce qui change la décision.
De là une distinction que presque toutes les listes en circulation manquent. Un défaut décrit l’état du système. Un red flag décrit l’écart entre cet état et ce qu’on vous en dit. Une couverture de tests à 12 %, c’est un défaut. On le constate, on le chiffre, on en discute. En revanche, un rapport de test d’intrusion dont trois constats critiques traînent depuis dix mois n’ajoute pas une ligne à la liste des défauts : il vous renseigne sur la façon dont cette entreprise traite ce qu’elle sait déjà.
La conséquence est très concrète. Un défaut se soustrait du prix. Un red flag jette un doute sur tout le reste, y compris sur les zones que vous n’aurez pas le temps d’aller voir.
II. Ce qui relève de la dissimulation
C’est la catégorie la plus grave, et celle que les listes génériques rangent au même niveau que le reste. Elle a pourtant une propriété que les autres n’ont pas : l’acquéreur n’achète pas une faiblesse, il achète une situation en cours dont il héritera sans en avoir rien su.
Un incident en cours dont personne ne parle
Il est rare qu’une équipe mente. Il est fréquent qu’elle attende d’avoir compris l’ampleur avant d’en parler, et que la due diligence tombe pile pendant cette attente. Le signal n’est alors pas dans le discours, il est dans l’activité : une rotation d’identifiants qui n’était prévue nulle part, des mises en production nocturnes sur un service secondaire, une astreinte renforcée que rien ne justifie dans la roadmap.
Situation fictive
Éditeur SaaS, quarante salariés. Au cadrage, on m’annonce « aucun incident de sécurité depuis la création ». En parcourant l’historique du dépôt d’infrastructure, je relève onze commits en trois jours sur la gestion des jetons d’API, dont sept entre 22 h et 2 h du matin, deux semaines avant mon arrivée. Aucun ticket, aucune trace en revue de code. Je pose la question au CTO : que s’est-il passé la nuit du 14 ? Réponse en trente secondes : un jeton de production avait été publié dans un dépôt ouvert par un prestataire. Révoqué, tracé, sans exploitation constatée.
La réaction technique a été rapide. Elle s’est arrêtée là. Pas de post-mortem, pas une ligne écrite, aucune revue de la manière dont ce jeton avait pu sortir, et rien qui empêche que cela recommence le mois suivant. Un incident sans gouvernance n’est pas un incident traité : c’est un incident éteint.
Le red flag était double. D’abord cette absence de trace, qui signifie que l’organisation n’apprend pas de ses incidents. Ensuite le fait que rien n’ait été déclaré, ni au conseil, ni à l’acquéreur, ni dans la data room. Et comme la réponse m’est venue en trente secondes, il était clair que personne n’avait oublié : on avait décidé de ne pas en parler.
Une fuite non corrigée, et surtout non notifiée
Ici le sujet cesse d’être technique. L’article 33 du RGPD impose de notifier une violation de données à l’autorité de contrôle sous 72 heures. L’article 34 impose d’en informer les personnes concernées quand le risque est élevé. Une violation non notifiée n’est donc pas un incident passé : c’est un manquement toujours en cours le jour du closing, qui relève des déclarations et garanties du contrat et ouvre un recours après l’opération.
Un acquéreur qui découvre cela trois mois après la signature ne négocie plus, il appelle son avocat. C’est pour cette raison que je traite ce point avant tous les autres dans mes rapports, avant même l’architecture.
Situation fictive
Plateforme grand public, deux millions de comptes. On me remet sans réticence le rapport de test d’intrusion de l’année précédente. Il mentionne une énumération d’identifiants : une adresse électronique suffit à savoir si un compte existe. Constat coté moyen, marqué corrigé dans le tableau de suivi. Je le rejoue. Il fonctionne toujours.
En remontant le fil, on découvre qu’un export de la table des comptes avait été récupéré par ce biais huit mois plus tôt, puis revendu. L’équipe l’avait vu passer, avait colmaté le symptôme le plus visible, et n’avait rien notifié. Ni à la CNIL, ni aux deux millions de personnes concernées. Personne n’avait pris la peine de qualifier l’événement de violation de données. Le sujet a quitté ma table pour celle des juristes dans la journée.
Des constats critiques ouverts depuis des mois
Le rapport existe, on vous le donne volontiers, et les constats de gravité haute y sont ouverts depuis trois campagnes. Le red flag n’est pas la vulnérabilité elle-même. C’est ce que la situation démontre : dans cette organisation, produire un rapport suffit à considérer le sujet comme réglé. Ce que vous apprenez là ne vaut pas que pour la sécurité. Cela vaut pour tout ce que vous n’aurez pas le temps de vérifier vous-même.
Un signalement externe resté sans réponse
Un chercheur qui écrit et n’obtient rien. Une adresse security@ sans destinataire. Un client qui remonte un comportement anormal et s’entend répondre que c’est normal. Ces signaux coûtent presque rien à vérifier, et personne ne les vérifie.
Dans les quatre cas, la question utile n’est pas « est-ce grave ? » mais « pourquoi ne me l’a-t-on pas dit ? ». C’est la réponse à celle-là qui décide de ce que valent tous vos autres constats.
III. Ce qui ne se corrige pas avec de l’argent
La deuxième famille regroupe ce qu’aucune ligne de budget ne résout, parce que le problème ne se situe pas dans le code.
La propriété du code n’est pas établie
Des prestataires sans clause de cession, des contributions antérieures à la création de la société, un fondateur parti dont la situation n’a jamais été régularisée. Le code tourne, il est même bon, et il n’appartient pas entièrement au vendeur. La question qui tranche est simple : pour chaque personne ayant écrit du code encore en production, existe-t-il un document signé qui cède les droits ? Le contrat de travail ne suffit pas toujours. Un contrat de prestation sans clause explicite ne suffit jamais.
Une personne que rien ne retient
Toutes les concentrations de savoir ne se valent pas. Quand une seule personne connaît une procédure, quelques semaines suffisent à corriger le tir. Quand une seule personne comprend le modèle de calcul, et qu’il faudrait deux ans à un successeur pour y arriver, aucun document n’y changera quoi que ce soit.
La bonne question n’est donc pas « qui est indispensable ? », à laquelle tout le monde répond en citant la même personne. C’est plutôt : s’il part demain, en combien de temps quelqu’un d’autre fait-il le même travail, et avec quel taux d’erreur pendant la transition ?
La production ne peut pas être reconstruite
Un test simple, et rarement fait : à partir du dépôt et d’une sauvegarde, combien de temps pour obtenir un environnement qui fonctionne ? Quand la réponse est « on n’a jamais essayé », ce n’est pas un problème de documentation. C’est une inconnue sur ce que vous achetez, parce qu’une partie du système n’existe alors que sous la forme d’une machine allumée que personne ne sait reproduire.
IV. Ce qui se négocie plutôt que se fuit
Les listes en circulation mettent sur le même plan des sujets qui ne jouent pas dans la même catégorie. Une dette technique chiffrable, une couverture de tests faible, une architecture qui ne tiendra pas le business plan, une supervision inexistante : ce sont des lignes de prix, pas des motifs de retrait.
La conversion se fait en deux temps. On identifie les seuls chantiers sans lesquels l’objectif visé reste hors d’atteinte, puis on les chiffre en jours-homme, et enfin en euros. C’est l’objet d’une autre note, Ce que coûte vraiment la dette technique.
Attention toutefois : un vendeur qui refuse de reconnaître un défaut pourtant mesurable fait basculer le sujet dans la catégorie II. Ce n’est plus la dette qui pose problème, c’est le désaccord sur un fait vérifiable.
V. Les faux red flags
Ceux-là inquiètent surtout les auditeurs qui appliquent une grille. Je les rencontre à chaque mission, et ils occupent souvent la place qui revenait aux vrais.
Une stack technique ancienne. Du PHP, du Java, du Rails de dixième génération. L’âge ne dit rien. Trois faits vérifiables, si : la version est-elle encore maintenue en amont, l’équipe livre-t-elle, recrute-t-on encore sur ce marché. Trois oui, et il n’y a pas de sujet. Une stack récente et mal maîtrisée reste bien plus risquée qu’une stack ancienne et bien tenue.
Un monolithe. Découper en services n’est pas une vertu, c’est une réponse à un problème de taille d’équipe. À trente ingénieurs, un monolithe bien structuré livre plus vite que quinze services aux frontières floues. Ce qui se mesure, c’est le délai entre un commit et sa mise en production, pas le nombre de dépôts.
Un code peu documenté. Je préfère un code lisible sans commentaires à un code abondamment commenté qu’il faut déchiffrer. De toute façon, la documentation qui compte n’est pas dans le code. Elle répond à d’autres questions : comment on déploie, quoi faire quand ça casse, pourquoi telle décision a été prise il y a trois ans.
Peu de tests unitaires. Une couverture faible sur un système stable depuis trois ans, avec peu d’incidents et des retours arrière rapides, en dit bien moins qu’une couverture de 80 % sur un système qui casse toutes les semaines. Regardez l’incidentologie avant le pourcentage.
Une petite équipe. La taille n’est pas un risque. La concentration des savoirs en est un, et ce sont deux choses différentes : quatre personnes qui se relaient sur tous les domaines vous exposent moins qu’une équipe de douze où chacun tient seul son périmètre.
VI. Ce qui n’apparaît jamais dans le dépôt
Après une vingtaine d’audits, ce qui m’a le plus surpris est que les signaux les plus fiables ne sont pas dans le code. Ils sont dans la façon dont l’équipe répond.
Le délai de réponse, et surtout ses variations. Une équipe répond en deux heures sur l’architecture et met trois jours à donner un accès à la production. Ce n’est pas la lenteur qui informe, c’est l’écart entre les deux.
Qui répond à la place de qui. Vous posez une question à l’ingénieur qui a écrit le module, c’est le CTO qui répond. Une fois, c’est de la politesse. Systématiquement, et toujours sur le même sujet, c’est une information.
L’accès promis qui n’arrive jamais. Convenu au cadrage, rappelé deux fois, toujours en attente d’une validation. Ou bien accordé, mais sur un environnement vidé de ses données. Ce qu’on vous refuse est souvent plus instructif que ce qu’on vous ouvre.
Deux versions d’un même événement. L’incident de l’an dernier a duré deux heures pour l’un, une demi-journée pour l’autre. Personne ne ment. Il n’existe simplement aucune source unique, ce qui est déjà un constat en soi.
La réponse trop préparée. Au milieu d’un entretien spontané, un sujet arrive avec une formulation manifestement répétée. Ce n’est pas une preuve. C’est une indication sur ce qui a été anticipé, donc sur ce qui inquiète en interne.
Une nuance s’impose, faute de quoi tout cela vire à la paranoïa. Une équipe en période de deal est sous tension, souvent mal informée de ce qu’elle a le droit de dire, et parfois inquiète pour son poste. Ces signaux vous disent où creuser, jamais quoi conclure. Un seul ne vaut rien. Trois qui pointent au même endroit valent une question directe.
VII. Hiérarchiser
Un signal ne sert à rien tant qu’il n’est pas classé. Quatre issues possibles selon les cas, et une seule est un retrait.
Ce qui peut arrêter : la dissimulation avérée, la propriété du code non établie. Ce qui peut se déduire du prix : tout ce qui se chiffre en jours-homme. Ce qui peut entrer en garantie : les risques identifiés mais non quantifiables, dont les manquements réglementaires en cours. Ce qui peut se traiter après : l’essentiel du reste, à condition d’être inscrit noir sur blanc dans le plan des cent premiers jours.
On classe sur deux axes, la gravité et la portée. Un troisième, moins souvent cité, tranche en pratique : la réversibilité. Un défaut grave mais réversible reste une ligne de budget. Un défaut moyen mais irréversible devient une condition. La grille complète est détaillée dans le rapport d’exemple.
Un dernier point, contre-intuitif : un red flag isolé n’arrête presque jamais une opération. C’est leur accumulation, ou leur dissimulation, qui la fait échouer.
VIII. Questions fréquentes
Un vendeur peut-il refuser l’accès au code source ?
Oui, et c’est fréquent avant l’exclusivité. Le refus, en soi, n’est pas un red flag : le code est l’actif, et l’ouvrir à un acquéreur qui pourrait ne pas signer se discute. Ce qui compte est ce qu’on propose à la place, revue en écran partagé, accès à un environnement de recette, métriques extraites par l’équipe. Le signal apparaît quand le refus ne s’accompagne d’aucune alternative, ou quand le périmètre refusé se déplace d’une demande à l’autre.
Comment repérer ses propres red flags avant une cession ?
En faisant l’exercice avant que l’acquéreur ne le fasse, ce qui est l’objet d’une vendor due diligence. Trois sujets méritent d’être traités en priorité, parce qu’ils ne se rattrapent pas dans le temps d’une négociation : la propriété du code, y compris celui écrit par d’anciens prestataires, la trace écrite des incidents passés, et la capacité démontrée à reconstruire la production. Les découvrir six mois avant laisse le temps de les corriger ; les découvrir en due diligence laisse le temps d’en discuter le prix.
Combien de temps faut-il pour identifier les red flags d’une cible ?
Une à deux semaines suffisent pour les signaux bloquants, à condition d’avoir les accès. C’est le format du red flag report, plus court qu’une due diligence complète, qui demande trois à six semaines. La contrainte n’est presque jamais le temps d’analyse : c’est le délai d’obtention des accès et des entretiens.