Due diligence technique dans le cadre d'acquisitions : ce que le code révèle sur l'entreprise

Une due diligence technique permet, avant la signature, d'examiner le contenu du code source d'une entreprise cible, d'identifier les risques qu'il recèle et de déterminer la valeur technique réelle d'une acquisition. Quiconque achète une entreprise achète également ses logiciels, que ceux-ci soient inclus ou non dans le prix d’achat. Selon le rapport mondial sur les fusions-acquisitions de Bain, plus de 70 % des transactions sur le segment intermédiaire du marché comportent une composante technologique significative, telle que Plausity comme l'indique le rapport (Plausity, 03/2026). Un prix d'achat fixé sur la base d'une analyse trop superficielle ne peut que rarement être corrigé a posteriori après la signature.

Ce que vérifie concrètement une due diligence technique

Un audit se limitant à des entretiens avec l’équipe de développement ne permet de mettre en évidence qu’une fraction des risques pertinents. Il doit aller au-delà des entretiens et examiner le code lui-même, la situation en matière de sécurité et l’origine de la propriété intellectuelle, car, dans la pratique, les déclarations faites lors des entretiens et l’état réel des systèmes divergent souvent. Ceux qui se fient aux présentations de la direction repèrent rarement les failles du système qui coûteront le plus cher lors de l'acquisition. Seuls ceux qui examinent eux-mêmes le code, plutôt que de se fier à un résumé, parviennent à identifier précisément ces failles.

Ces six domaines sont liés : une faiblesse dans l'un d'entre eux accentue généralement les risques dans les autres. En l'absence de documentation, le risque lié aux personnes clés prend davantage d'importance. En l'absence de couverture de test, toute évolution de l'architecture devient plus risquée qu'elle ne le semble sur le papier.

En ce qui concerne l'origine de la propriété intellectuelle, il convient d'examiner attentivement les contrats. Selon § 69b de la loi allemande sur le droit d'auteur (UrhG) Sauf convention contraire, les droits patrimoniaux sur les logiciels créés par les salariés dans l'exercice de leurs fonctions reviennent à l'employeur. Cette règle ne s'applique pas aux collaborateurs indépendants. Dans ce cas, un transfert explicite des droits doit être prévu dans le contrat, ce qui fait souvent défaut dans les bases de code qui se sont développées au fil des années.

Dans les audits que nous menons, une tendance revient sans cesse. Les systèmes présentant une bonne couverture de test disposent presque toujours d’une documentation plus claire, car ces deux éléments découlent de la même rigueur de travail au sein de l’équipe de développement. Lorsque ces deux éléments font défaut simultanément, cela constitue un signal d’alerte plus fort que n’importe laquelle de ces valeurs prise isolément.

Pourquoi la dette technique influe sur le prix d'achat

La dette technique peut être mesurée à l'aide d'un indicateur, contrairement à l'impression vague que l'on peut retirer d'une simple conversation. Des dépendances obsolètes, l'absence de tests et une architecture qui transforme chaque modification en risque entraînent, après l'acquisition, des coûts supplémentaires réels, qu'il s'agisse de travaux de retouche, de retards dans le développement ultérieur ou d'un risque accru de panne pendant l'exploitation. Ces coûts ont un impact direct sur le retour sur investissement de la transaction, quelle que soit l’efficacité du modèle économique lui-même.

La quantification de ces dettes n’est donc pas un simple exercice théorique. Elle sert de base à la négociation du prix d’achat et à l’élaboration d’un „ plan des 100 premiers jours “ réaliste après la reprise, période durant laquelle les risques les plus urgents doivent être traités avant qu’ils n’entraînent des défaillances ou des incidents de sécurité. Un montant figurant dans le contrat de vente et fondé sur ce chiffre est plus facile à justifier devant un comité qu’une décote forfaitaire fixée au feeling.

Dans la pratique, le montant ainsi déterminé est généralement intégré à la transaction de l'une des deux manières suivantes : soit le prix d'achat est réduit du montant estimé des coûts consécutifs, soit une partie du prix d'achat est bloquée dans le cadre d'un mécanisme d'entiercement jusqu'à ce que les points les plus critiques aient été résolus. Le choix de la méthode appropriée dépend du poids de chacune des parties dans la négociation, et non pas uniquement du montant des dettes constatées. L'article montre à quel point ces travaux de remise en état peuvent s'avérer coûteux. Projet ERP en crise : schémas typiques et solutions.

Foire aux questions

Combien de temps dure une due diligence technique ?

Pour obtenir un premier aperçu fiable, une à deux semaines suffisent souvent, avec une petite équipe ayant accès au code, au système de tickets et aux principaux interlocuteurs. Les transactions de plus grande envergure, impliquant plusieurs gammes de produits ou des équipes dispersées, nécessitent naturellement plus de temps, surtout s’il faut d’abord organiser les accès avant que l’audit proprement dit puisse commencer. Fixer un calendrier précis dès le départ est utile pour les deux parties, car cela évite que l’audit ne s’éternise discrètement pendant des semaines et ne retarde l’ensemble du processus de transaction.

Quels sont les critères d'exclusion habituels ?

Parmi ceux-ci figurent des situations de propriété floues concernant le code, par exemple lorsque des parties essentielles proviennent de collaborateurs indépendants sans transfert de droits documenté, des failles de sécurité graves dans les systèmes de production, ainsi qu’une architecture qui ne peut évoluer qu’au prix d’une refonte quasi totale. Aucun de ces critères n'exclut automatiquement une transaction, mais ils ont une incidence considérable sur le prix d'achat ou la structure de l'opération, par exemple en prolongeant la période de responsabilité du vendeur ou en retenant une partie du prix d'achat.

Qui devrait procéder à cette vérification ?

Une équipe disposant d'une véritable expérience en matière de développement fournit des résultats différents de ceux de simples consultants qui n'ont eux-mêmes jamais été responsables de code productif. La personne chargée de remédier aux risques identifiés après la reprise doit, dans l'idéal, être impliquée dès la phase d'audit, ce qui raccourcit considérablement la transition entre l'évaluation et l'intégration effective. Dans la pratique, un simple rapport d’audit sans responsabilité quant à la mise en œuvre finit souvent dans un tiroir, au lieu de déboucher sur des mesures concrètes.

Une due diligence technique n'a de valeur que dans la mesure où l'on est capable de remédier par la suite aux risques identifiés. torck examine les entreprises cibles avec les mêmes équipes de développement basées à Maxhütte-Haidhof, Vienne et Rabat, qui se chargent ensuite de la Intégration technique dans le cadre d'une mission temporaire peuvent prendre en charge, au lieu de se contenter de transmettre les résultats dans un rapport. Le partenaire contractuel chargé de l'audit est la société allemande torck GmbH, ce qui facilite le respect de la confidentialité pendant une transaction en cours. Si vous avez besoin d'une évaluation technique avant une acquisition, vous pouvez le faire dans un Premier entretien .

Prendre rendez-vous