Due diligence technique en M&A : ce que les CTO sont censés faire

J'ai été des deux côtés du M&A. Chez Namespace Group, j'ai mené la due diligence technique sur des acquisitions en tant que CTO acquéreur. Chez vyzVoice, c'est moi qui étais évalué. Cette double perspective change l'approche, parce qu'on sait ce que ça fait d'avoir sa base de code ouverte et jugée par quelqu'un qui n'a pas le contexte.

La plupart des processus de due diligence technique en M&A souffrent du même défaut : ils produisent des documents que personne n'utilise. Quelqu'un parcourt une checklist, signale quelques éléments comme « risque moyen », et la transaction se conclut quand même. Trois mois plus tard, la société acquéreuse découvre que l'infrastructure de la cible est un monolithe qui tourne sur un seul serveur dans la cave de quelqu'un, ou que le CTO fondateur détient toute la propriété intellectuelle à titre personnel, ou que la plateforme entière dépend d'une librairie qui n'est plus maintenue depuis 2018. Rien de tout ça n'est surprenant. C'était identifiable. On n'a simplement pas regardé assez sérieusement.

Le processus de due diligence technique existe précisément pour prévenir ça. Bien mené, il devrait soit révéler des problèmes rédhibitoires suffisamment tôt, soit informer la valorisation avec des coûts de remédiation concrets, soit donner à l'équipe acquéreuse le contexte nécessaire pour planifier une intégration réaliste. Parfois les trois à la fois.

À quoi ressemble vraiment ce travail

La version théorique de la due diligence technique donne une liste bien rangée : réviser l'architecture, auditer le code, vérifier la conformité des licences open source, évaluer la posture de sécurité, examiner les contrats fournisseurs. Ce n'est pas faux. C'est juste incomplet, et ça rate l'essentiel : le jugement.

Vous ne faites pas un audit de conformité. Vous cherchez à comprendre ce que cette technologie vaut réellement, ce qu'il en coûtera de la maintenir et de l'intégrer, et si l'équipe qui l'a construite peut fonctionner dans une nouvelle organisation. Ça demande plus que lire de la documentation. Ça demande de poser des questions inconfortables, de lire entre les lignes de ce qu'on vous montre, et de savoir à quoi ressemble une ingénierie saine à l'échelle.

Quand j'aborde une évaluation technologique pour une acquisition, la première chose que je cherche c'est l'écart entre le récit officiel et la réalité opérationnelle. Chaque société cible présente son architecture comme plus propre qu'elle ne l'est. Ce n'est pas de la malhonnêteté — c'est ce que les fondateurs croient sincèrement. Mais les convictions et la réalité divergent au fil des années à shipper sous pression. Votre travail est de trouver cette divergence.

Le rôle du CTO avant le début du processus

Avant d'ouvrir un seul dépôt de code, vous devez comprendre la thèse de l'acquisition. Achetez-vous la technologie ? L'équipe ? La base de clients ? La position de marché ? Chacun de ces objectifs change ce qu'il faut chercher.

Si vous achetez la technologie, la qualité du code et l'architecture comptent énormément. Si vous achetez l'équipe, vous faites en réalité une évaluation de talents avec quelques éléments techniques autour. Si vous achetez une position de marché, la technologie peut être largement secondaire du moment qu'elle ne s'effondre pas au mauvais moment.

Comprendre ça est fondamental. Vous risquez sinon de passer du temps à auditer des choses qui n'impactent pas le deal, en manquant celles qui le déterminent.

Obtenez les accès tôt. Vous voulez un accès direct aux dépôts, pas des captures d'écran triées sur le volet. Vous voulez parler aux ingénieurs, pas seulement au CTO. Vous voulez un accès à l'infrastructure ou du moins une architecture documentée avec de vrais chiffres — volumes de requêtes réels, taux d'erreurs réels, historique réel des incidents d'astreinte. Tout ce qui passe par le filtre de la communication de la cible est déjà biaisé.

Ce qu'il faut vraiment chercher

La dette technique est normale. La dette technique non déclarée est un problème de valorisation.

Toute entreprise porte une dette technique. C'est inévitable. La question est de savoir si les dirigeants connaissent ce qu'ils ont et peuvent en articuler le coût. Si le CTO peut vous donner une image claire de leur dette, l'équipe fonctionne probablement bien. S'ils vous répondent « on a quelques composants legacy » sans précision, vous avez affaire soit à du déni, soit à une équipe qui n'a pas fait le travail interne pour comprendre sa propre base de code.

Regardez le ratio de temps consacré aux nouvelles fonctionnalités versus la maintenance et la gestion des incidents. Si les ingénieurs passent plus de 30 à 40 % de leur temps à maintenir les systèmes existants plutôt qu'à construire, c'est un signal que la dette prélève déjà une vraie taxe opérationnelle.

L'architecture vous dit la trajectoire, pas seulement l'état actuel.

Ce système peut-il évoluer ? Peut-on le modifier sans risque de réaction en chaîne ? Les composants sont-ils suffisamment découplés pour extraire ou remplacer des parties sans tout reconstruire ? Les réponses importent moins pour l'état actuel de la société que pour là où l'acquéreur doit l'emmener.

Méfiez-vous des monolithes distribués : des systèmes qui ressemblent à des microservices sur le papier mais partagent une base de données unique, ou ont tellement d'appels synchrones entre services que la défaillance d'un seul fait tomber tout l'ensemble. Ils cumulent la complexité opérationnelle des microservices sans aucun des bénéfices de résilience. Ils coûtent cher à corriger.

La posture de sécurité est non-négociable dans certains secteurs.

Chez EBRAND, nous travaillons dans la protection contre les risques numériques. La sécurité n'est pas une catégorie de fonctionnalités pour nous — c'est le produit. Quand j'évalue une acquisition dans cet espace, l'hygiène sécurité me dit beaucoup sur la culture d'ingénierie. Les secrets sont-ils gérés correctement ou hardcodés dans le code ? Les dépendances sont-elles scannées pour les vulnérabilités ? Y a-t-il un journal d'audit des accès ? Ont-ils eu un test d'intrusion dans les deux dernières années ?

Dans les secteurs où une faille serait catastrophique — fintech, santé, gestion d'identités, tout ce qui touche aux données réglementées — la dette de sécurité a besoin d'un budget de remédiation concret avant que les termes de la transaction soient finalisés.

La propriété intellectuelle est une question juridique, mais c'est le CTO qui doit la poser.

Qui est réellement propriétaire du code ? Est-il cédé à la société, ou réside-t-il dans des comptes personnels des fondateurs ? Y a-t-il des contributions de prestataires ou de projets open source qui n'ont pas été traitées proprement ? La société a-t-elle respecté les licences open source, ou y a-t-il du code GPL enfoui dans un produit propriétaire ?

Les réponses à ces questions impactent la valeur de ce que vous achetez. Un désordre de propriété intellectuelle peut se régler, mais ça prend du temps et du travail juridique, et les deux coûtent de l'argent. Ce coût appartient au modèle financier de la transaction.

Les dépendances aux fournisseurs et les dépendances critiques méritent un examen sérieux.

Regardez chaque relation fournisseur critique : cloud provider, processeur de paiement, plateforme de communication, fournisseurs de données. La stack est-elle portable ? S'ils tournent sur un service cloud propriétaire sans chemin de migration propre, c'est du vendor lock-in. Si leur infrastructure de recherche est un service managé sans option d'export, c'est une dépendance qui contraint vos options d'intégration.

La gouvernance des données appartient à la même catégorie. Où sont stockées les données clients ? Quelle juridiction ? La conformité RGPD est-elle documentée et opérationnelle, ou s'agit-il d'un PDF de 2018 que personne n'a revisité ? Pour les acquisitions européennes, la résidence des données et les accords de traitement ne sont pas des formalités.

L'équipe est généralement la variable la plus importante.

Les bases de code peuvent être réécrites. Les systèmes peuvent être remplacés. Mais si les trois ingénieurs qui comprennent vraiment comment la plateforme fonctionne partent dans les six mois suivant l'acquisition, vous avez perdu quelque chose qui ne se récupère pas facilement.

Ayant été des deux côtés, acquéreur et acquis, le risque lié aux équipes s'est systématiquement révélé plus difficile à quantifier que la dette technique, mais plus déterminant quand il se matérialisait. Vous devez comprendre qui sont les personnes clés, ce qu'elles maîtrisent, si elles sont susceptibles de partir, et comment elles perçoivent l'acquisition. Les ingénieurs sont perspicaces — ils savent souvent plus de choses sur ce qui se passe qu'ils ne le laissent paraître.

Faites attention à la dynamique humaine : y a-t-il une équipe qui travaille ensemble depuis des années avec une vraie confiance interne ? Ou observe-t-on un turnover élevé, une documentation superficielle, et une culture où la connaissance est thésaurisée ? Ce dernier profil ne signale pas seulement des problèmes d'équipe. Il signale une fragilité opérationnelle.

Les signaux d'alerte et leur signification réelle

Certains signaux d'alerte en due diligence technique sont sans ambiguïté : pas d'historique de contrôle de version, pas de tests automatisés, infrastructure de production sans monitoring, une équipe où une seule personne est le point de défaillance unique pour tous les systèmes critiques. Ce ne sont pas des opinions. Ce sont des risques concrets et quantifiables.

D'autres sont plus nuancés. Une base de code ancienne n'est pas automatiquement mauvaise. Un monolithe n'est pas automatiquement mauvais. La question est toujours : étant donné l'objectif post-acquisition, qu'est-ce que ça va vraiment coûter ?

Le cadrage le plus utile que j'ai trouvé consiste à transformer chaque constat en coût estimé. Pas un vague label « risque moyen », mais un chiffre réel : ça prendra trois ingénieurs six mois à corriger, voilà un budget de remédiation spécifique. Un audit de sécurité coûtera X. Une migration cloud coûtera Y et prendra Z mois avec la capacité actuelle de l'équipe.

Quand vous présentez les signaux d'alerte comme des coûts plutôt que des catégories, ils deviennent actionnables. L'équipe de transaction peut les incorporer dans la valorisation. L'équipe d'intégration peut planifier en conséquence. « Risque moyen » n'aide personne.

La période post-acquisition

La plupart des processus de due diligence technique s'arrêtent au term sheet. C'est trop tôt.

Le CTO qui a mené la due diligence devrait piloter les cent premiers jours d'intégration technique. Il dispose d'un contexte que personne d'autre n'a : ce qui a été trouvé, ce qui a été promis, ce qui a été minimisé. Confier la planification de l'intégration à quelqu'un qui n'a pas participé à la due diligence, c'est perdre la connaissance institutionnelle que le processus a générée.

Les équipes d'ingénierie des deux côtés d'une acquisition sont presque toujours anxieuses. Les acquisitions signifient l'incertitude : sur les rôles, sur les systèmes qui survivent, sur la valeur du travail accompli. Le rôle du CTO acquéreur est d'être visible, honnête et clair sur le plan. Tout ne doit pas être décidé immédiatement, mais le vide se remplit de rumeurs plus vite qu'on ne le pense.

Traitez l'équipe acquise comme des professionnels qui ont construit quelque chose qui valait la peine d'être acheté, même si ça a des aspérités. Ils connaissent leur système mieux que vous. La due diligence doit avoir déjà identifié les personnes clés — assurez-vous que ces personnes aient une raison claire de rester.

Une note sur le CTO fractionnaire en M&A

Toutes les sociétés qui traversent une acquisition n'ont pas en interne un leader technique avec de l'expérience M&A. Le CTO interne est peut-être excellent pour piloter l'ingénierie produit, mais n'a jamais conduit une évaluation technologique à ce niveau. Ou la société acquéreuse est un fonds de private equity qui achète des entreprises technologiques mais n'a pas de leader technique en interne.

Faire appel à un CTO fractionnaire pour la due diligence technique M&A est une option sous-utilisée. Ce n'est pas seulement une question de combler un manque de compétences. Un leader technique externe apporte une objectivité que les personnes en interne ont parfois du mal à maintenir. Il n'est pas investi politiquement dans la réussite du deal. Il peut dire « c'est pire que ce qui a été présenté » sans se soucier des relations internes.

Une mission de due diligence avec un CTO fractionnaire ressemble généralement à ceci : deux à quatre semaines d'accès intensif, couvrant l'architecture, le code, des entretiens avec l'équipe, la posture de sécurité, la propriété intellectuelle et l'écosystème fournisseurs. Le livrable est un rapport de risques techniques avec des coûts associés, des recommandations pour les termes de la transaction, et une feuille de route d'intégration proposée. Après la clôture, il peut rester pour superviser la première phase d'intégration.

C'est une utilisation à fort effet de levier de ce format. Quelques semaines d'un regard technique expérimenté peuvent faire évoluer la structure d'une transaction de manière à se rentabiliser plusieurs fois.

---

Si vous traversez une acquisition et avez besoin de quelqu'un qui a déjà fait ça, je propose des services de CTO fractionnaire incluant la due diligence technique M&A. Réserver un appel découverte →