Due diligence technique en M&A : ce que le CTO est vraiment censé faire

J'ai connu les deux côtés du M&A. Chez Namespace Group, j'ai piloté la due diligence technique sur des acquisitions en tant que CTO côté acquéreur. Chez vyzVoice, c'est moi qu'on évaluait. Cette double perspective change la façon d'aborder le travail : on sait ce que ça fait d'avoir sa base de code épluchée par quelqu'un qui n'a pas votre contexte.

La plupart des processus de due diligence technique en M&A ont le même défaut : ils produisent des documents que personne n'exploite. Quelqu'un déroule une checklist, colle quelques étiquettes « risque moyen », et le deal se conclut quand même. Trois mois plus tard, l'acquéreur découvre que l'infra de la cible est un monolithe qui tourne sur un serveur unique dans la cave de quelqu'un, que le CTO fondateur détient toute la propriété intellectuelle à titre personnel, ou que la plateforme entière repose sur une librairie abandonnée depuis 2018. Rien de tout ça n'est une surprise. C'était détectable. Personne n'a regardé assez sérieusement.

La due diligence technique existe pour empêcher ça. Bien menée, elle doit soit faire remonter les problèmes rédhibitoires assez tôt, soit alimenter la valorisation avec des coûts de remédiation concrets, soit donner à l'acquéreur le contexte nécessaire pour planifier une intégration réaliste. Parfois les trois.

Le travail, concrètement

La version théorique de la due diligence technique donne une liste bien propre : revoir l'architecture, auditer le code, vérifier la conformité des licences open source, évaluer la posture de sécurité, passer en revue les contrats fournisseurs. Ce n'est pas faux. C'est juste incomplet, et ça passe à côté de l'essentiel : le jugement.

On ne fait pas un audit de conformité. On cherche à comprendre ce que cette technologie vaut vraiment, 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 de lire de la documentation. Ça demande de poser des questions gênantes, de lire entre les lignes de ce qu'on vous présente, et de savoir reconnaître une ingénierie saine à l'échelle.

Quand j'attaque une évaluation techno pour une acquisition, la première chose que je cherche, c'est l'écart entre le discours officiel et la réalité opérationnelle. Chaque 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, année après année, sous la pression des livraisons. Le boulot, c'est de trouver cette divergence.

Le rôle du CTO avant de commencer

Avant d'ouvrir le moindre dépôt, il faut comprendre la thèse d'acquisition. On achète la technologie ? L'équipe ? La base clients ? La position de marché ? Chaque réponse change ce qu'on doit chercher.

Si c'est la technologie, la qualité du code et l'architecture comptent énormément. Si c'est l'équipe, on fait en réalité une évaluation de talents habillée de technique. Si c'est la position de marché, la techno peut être largement secondaire — du moment qu'elle ne s'effondre pas au mauvais moment.

Se tromper là-dessus, c'est passer du temps à auditer des choses sans impact sur le deal en ratant celles qui le déterminent.

Il faut obtenir les accès tôt. Accès direct aux dépôts, pas des captures d'écran triées sur le volet. Parler aux ingénieurs, pas seulement au CTO. Accéder à l'infrastructure ou au minimum à 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 com 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 de la dette technique. C'est inévitable. La question, c'est de savoir si la direction connaît l'étendue de la sienne et sait en chiffrer le coût. Si le CTO est capable de vous en donner une image claire, l'équipe tourne probablement bien. S'il vous sort un vague « on a quelques composants legacy » sans rien de précis, vous êtes face à du déni ou à une équipe qui n'a jamais pris le temps de comprendre sa propre base de code.

Regardez le ratio entre le temps passé sur les nouvelles fonctionnalités et celui consacré à la maintenance et à l'extinction d'incendies. Si les ingénieurs passent plus de 30 à 40 % de leur temps à maintenir l'existant plutôt qu'à construire, c'est le signe que la dette prélève déjà une vraie taxe opérationnelle.

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

Ce système peut-il passer à l'échelle ? Peut-on le modifier sans effet domino ? Les composants sont-ils assez découplés pour qu'on puisse en extraire ou en remplacer sans tout reconstruire ? Les réponses comptent moins pour l'état actuel de la boîte que pour là où l'acquéreur devra l'emmener.

Attention aux monolithes distribués : des systèmes qui ressemblent à des microservices sur le papier mais partagent une seule base de données, ou dont les appels synchrones entre services sont si nombreux que la panne d'un seul fait tout tomber. On cumule la complexité opérationnelle des microservices sans aucun bénéfice de résilience. C'est coûteux à corriger.

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

Chez EBRAND, on travaille en Digital Risk Protection. La sécurité n'est pas une catégorie de fonctionnalités chez nous — c'est le produit. Quand j'évalue une acquisition dans cet espace, l'hygiène sécurité m'en dit long sur la culture d'ingénierie. Les secrets sont-ils gérés proprement ou hardcodés dans le code ? Les dépendances sont-elles scannées ? Y a-t-il un vrai journal d'audit des accès ? Un pentest a-t-il eu lieu 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 sécurité doit être chiffrée en budget de remédiation avant que les termes du deal ne soient bouclés.

La propriété intellectuelle est une question juridique, mais c'est au CTO de la poser.

Qui détient réellement le code ? Est-il assigné à la société, ou vit-il sur les 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 boîte 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 impactent directement la valeur de ce qu'on achète. Un désordre de propriété intellectuelle, ça se nettoie, mais ça prend du temps et du travail juridique — les deux coûtent de l'argent. Ce coût doit figurer dans le modèle financier du deal.

Le vendor lock-in et les dépendances critiques méritent un examen sérieux.

Passez en revue chaque relation fournisseur critique : cloud provider, processeur de paiement, plateforme de communication, fournisseurs de données. La stack est-elle portable ? Si tout tourne sur un service cloud propriétaire sans chemin de migration propre, c'est du vendor lock-in. Si l'infra de recherche est un service managé sans option d'export, c'est une dépendance qui réduit les options d'intégration.

La gouvernance des données relève de la même catégorie. Où sont stockées les données clients ? Dans quelle juridiction ? La conformité RGPD est-elle documentée et opérationnelle, ou c'est un PDF de 2018 que personne n'a rouvert ? En Europe, la résidence des données et les accords de traitement ne sont pas des formalités.

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

Une base de code, ça se réécrit. Un système, ça se remplace. Mais si les trois ingénieurs qui comprennent vraiment comment la plateforme fonctionne partent dans les six mois après l'acquisition, on a perdu quelque chose qui ne se récupère pas facilement.

Pour avoir vécu les deux côtés — acquéreur chez Namespace Group, acquis chez vyzVoice — le risque humain s'est toujours révélé plus difficile à quantifier que la dette technique, mais plus déterminant quand il se matérialisait. Il faut comprendre qui sont les personnes clés, ce qu'elles maîtrisent, si elles risquent de partir, et comment elles perçoivent l'acquisition. Les ingénieurs sont perspicaces — ils en savent souvent bien plus sur ce qui se passe qu'ils ne le laissent voir.

Regardez la dynamique humaine : une équipe qui travaille ensemble depuis des années avec une vraie confiance, ou bien un turnover élevé, une documentation superficielle, une culture où la connaissance est thésaurisée ? Le second profil ne signale pas seulement des problèmes d'équipe. Il signale une fragilité opérationnelle.

Les signaux d'alerte et ce qu'ils veulent vraiment dire

Certains red flags sont sans ambiguïté : pas d'historique de versioning, pas de tests automatisés, une production sans monitoring, une équipe où une seule personne est le single point of failure de 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 forcément un problème. Un monolithe non plus. La question reste toujours : vu l'objectif post-acquisition, combien ça va vraiment coûter ?

Le cadrage le plus utile que j'aie trouvé, c'est de transformer chaque constat en coût estimé. Pas un vague « risque moyen », mais un chiffre : il faudra trois ingénieurs pendant six mois pour corriger ça, voici le budget de remédiation. Un audit sécurité coûtera X. Une migration cloud coûtera Y et prendra Z mois avec la capacité actuelle de l'équipe.

Quand on présente les signaux d'alerte comme des coûts plutôt que comme des catégories, ils deviennent actionnables. L'équipe deal peut les intégrer à la valorisation. L'équipe d'intégration peut planifier en conséquence. « Risque moyen », ça n'aide personne.

L'après-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 a 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 toute 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. Une acquisition, c'est de l'incertitude : sur les rôles, sur les systèmes qui survivent, sur la valeur du travail accompli. Le CTO acquéreur doit être visible, honnête et clair sur le plan. Tout n'a pas besoin d'être décidé tout de suite, mais le vide se remplit de rumeurs bien plus vite qu'on ne le croit.

Il faut traiter l'équipe acquise comme des professionnels qui ont construit quelque chose qui valait la peine d'être acheté, même avec des aspérités. Ils connaissent leur système mieux que vous. La due diligence a normalement identifié les personnes clés — il faut que ces personnes aient une raison claire de rester.

Le CTO fractionnaire en M&A

Toutes les sociétés engagées dans une acquisition n'ont pas en interne un leader technique avec de l'expérience M&A. Le CTO en place est peut-être excellent pour piloter l'ingénierie produit, mais il n'a jamais mené une évaluation technologique à ce niveau. Ou bien l'acquéreur est un fonds de private equity qui achète des entreprises tech sans avoir de leader technique en interne.

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

En pratique, une mission de due diligence avec un CTO fractionnaire, ça ressemble à 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 chiffrés, des recommandations pour les termes du deal, et une feuille de route d'intégration. Après le closing, le CTO fractionnaire peut rester pour superviser la première phase d'intégration.

C'est un usage à fort effet de levier. Quelques semaines d'un regard technique expérimenté peuvent modifier la structure d'un deal de manière à se rentabiliser plusieurs fois.

---

Si vous êtes en cours d'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 →