Due diligence technique : ce qui manque aux investisseurs et aux acquéreurs

75 % des investisseurs classent désormais la maturité numérique parmi les trois principaux moteurs de valeur de l'entreprise.Ce chiffre provient du rapport mondial sur le capital-investissement 2025 de Bain. Cela signifie que la technologie n'est plus une préoccupation de back-office lors des acquisitions ; c'est un premier levier de valorisation.

Et pourtant, la plupart des contrôles techniques préalables ont lieu trop tard, couvrent trop peu et ne prennent pas en compte les risques qui explosent après la clôture. Le playbook standard charge un analyste junior de parcourir les diagrammes d'architecture, de vérifier les violations de licence open source et de produire un PDF de 40 pages que personne ne lit jusqu'à ce que quelque chose se brise.

Cet article explique à quoi ressemble un processus technique approfondi de DD, les domaines dans lesquels la plupart des avis échouent et les domaines spécifiques que vous devez évaluer avant de signer.

Pourquoi la DD technique est plus importante aujourd'hui qu'il y a cinq ans

Il y a cinq ans, une société de capital-investissement acquérant une activité générant un chiffre d'affaires de 50 millions de dollars pouvait traiter la pile technologique comme un élément de campagne. Si le produit fonctionnait, le code était « assez bon ». La valeur résidait dans les revenus, les contrats clients et le capital de marque.

Ce calcul a changé. Les multiples SaaS se compriment lorsque les acheteurs découvrent une dette technologique qui nécessite 12 à 18 mois de remédiation. Les délais d'intégration doublent lorsque les API ne sont pas documentées ou sont étroitement liées à un seul fournisseur. Les coûts du cloud s'envolent lorsque l'infrastructure est provisionnée par conjectures plutôt que par tests de charge. Ces surprises érodent la thèse valeur qui justifiait le prix d’acquisition.

Une étude McKinsey de 2024 a révélé que40 % des transformations technologiques post-acquisition dépassent leur budget initial de plus de 50 %. La cause profonde dans la plupart des cas : des risques qui existaient avant la clôture mais qui n'ont pas été identifiés lors des due diligences.

Les cinq risques cachés qui échappent aux examens DD standards

1. Architecture fragile sous charge

Le produit fonctionne bien aux niveaux de trafic actuels. Mais la thèse de l'acquisition suppose une croissance 3x sur 24 mois. L’architecture s’en chargera-t-elle ? La plupart des critiques de DD ne répondent jamais à cette question car elles ne la testent jamais. Ils examinent les diagrammes. Ils n'exécutent pas de simulations de charge.

Un modèle d'échec courant : l'application utilise une base de données monolithique sans réplicas en lecture, sans couche de mise en cache et des requêtes qui analysent des tables complètes. Avec 10 000 utilisateurs actifs quotidiens, les temps de réponse sont inférieurs à 200 ms. À 30 000 DAU, ces mêmes requêtes prennent 2 à 4 secondes. À 50 000, la base de données se verrouille en cas de conflit d'écriture et le produit tombe en panne. Il s'agit d'un coût de remédiation compris entre 500 000 et 2 millions de dollars que l'équipe du vendeur ne proposera pas.

2. Coûts imprévisibles du cloud

L'entreprise cible déclare 8 000 $/mois de dépenses cloud. L'équipe DD le note et passe à autre chose. Ce qu'ils ne vérifient pas : l'infrastructure n'a pas de politiques d'autoscaling, pas d'instances réservées et pas d'alertes de coûts. Trois environnements de développement fonctionnent 24h/24 et 7j/7 selon les spécifications du niveau de production. Un cluster Kubernetes oublié coûte 1 200 $/mois et ne sert à rien.

Après l'acquisition, lorsque le nouveau propriétaire pousse la croissance, les coûts du cloud grimpent à 25 000 $/mois parce que personne n'a optimisé les fondations. Le montant réel serait toujours de 25 000 $ ; le chiffre de 8 000 dollars reflète une sous-utilisation et non une efficacité.

3. Dépendances non documentées et savoirs tribaux

Le CTO a construit le système original il y a quatre ans. Deux ingénieurs l'ont rejoint plus tard. Tous les trois ont en tête tout le contexte architectural. Aucun enregistrement de décision d’architecture n’existe. Pas de runbooks. Aucun manuel de réponse aux incidents. Le processus de déploiement implique une connexion SSH sur un serveur et l'exécution d'un script bash qu'une personne a écrit et qu'une autre personne comprend.

Lorsque le CTO quitte l'entreprise après l'acquisition (et les CTO partent souvent dans les 12 mois suivant la clôture), l'équipe restante ne peut pas livrer de fonctionnalités, déboguer les problèmes de production ou intégrer de nouveaux ingénieurs sans des mois de rétro-ingénierie. Ce n'est pas un problème technique. Il s'agit d'un risque de continuité d'activité, et il doit être quantifié lors de la DD.

4. Faible reprise après sinistre

Posez deux questions à l'entreprise cible : « Quand avez-vous effectué pour la dernière fois une restauration à partir d'une sauvegarde ? » et "Quel est votre objectif de temps de récupération ?" Si les réponses sont « jamais » et « nous n’en avons pas défini », la posture de reprise après sinistre est un handicap.

De nombreuses entreprises mettent en place des sauvegardes automatisées lors du déploiement initial et ne les vérifient jamais. Les bases de données sont sauvegardées sur S3 la nuit, mais personne n'a testé si ces sauvegardes restaient en état de fonctionnement. La sauvegarde est peut-être corrompue. Le script de restauration peut faire référence à une infrastructure qui n'existe plus. Vous ne le saurez que lorsque vous en aurez besoin, et d’ici là, vous aurez perdu des données et des revenus.

5. Bloqueurs d'intégration

La valeur d'acquisition dépend souvent de l'intégration du produit de la cible à la plateforme existante de l'acheteur. Un outil CRM acquis par une suite d'entreprise doit se connecter au SSO, à la facturation partagée et aux analyses unifiées. Si le système d'authentification de la cible est une solution personnalisée codée en dur pour un seul fournisseur d'identité, cette intégration prend 6 mois au lieu de 6 semaines.

Les révisions DD doivent cartographier chaque surface d'intégration : API, webhooks, flux d'authentification, formats de données et systèmes d'événements. Chacun a besoin d'une évaluation honnête de la quantité de travail nécessaire pour se connecter à la pile de l'acheteur. "Nous avons une API" n'est pas la même chose que "Nous avons une API documentée, versionnée et à débit limité avec une authentification standard et une gestion des erreurs".

La check-list technique DD

Ce tableau couvre les domaines qu'un examen technique approfondi du DD devrait évaluer. Chaque domaine comprend des questions spécifiques auxquelles il faut répondre et le niveau de risque s'il n'est pas examiné.

Cette liste de contrôle couvre la surface technique. Un engagement DD complet comprend également des entretiens avec l'équipe d'ingénierie, un examen de la vitesse du sprint et de la cadence de livraison, ainsi qu'une évaluation commerciale de la feuille de route du produit.

Quand exécuter la DD technique (indice : plus tôt que vous ne le pensez)

La plupart des entreprises planifient le DD technique après avoir signé une lettre d'intention. À ce stade, l’accord a pris de l’ampleur. Les partenaires sont émotionnellement investis. L’entreprise cible sait qu’elle est en position de force pour négocier. Découvrir un coût de remédiation de 2 millions de dollars à ce stade crée un choix inconfortable : renégocier le prix (ce qui peut tuer la transaction) ou absorber le coût (ce qui érode les rendements).

Exécutez une DD technique pré-LOI ou parallèlement à la due diligence commerciale.Une évaluation technique légère prend 5 à 10 jours ouvrables et coûte une fraction de la valeur de la transaction. Il vous donne les informations dont vous avez besoin pour évaluer correctement la transaction dès le départ.

Les premières technologies DD font trois choses. Premièrement, il identifie les problèmes avant que vous n’engagez des frais de capital et de justice. Deuxièmement, il vous fournit des points de données spécifiques pour négocier des ajustements de prix liés aux coûts de remédiation. Troisièmement, cela réduit les frictions liées aux transactions ; Lorsque les deux parties voient tôt la réalité technique, il n’y a pas de surprises tardives qui retardent la clôture.

À quoi ressemble une bonne sortie technique DD

Un rapport DD utile n'est pas un document de 60 pages rempli de diagrammes d'architecture et de jargon. C'est un outil de décision. Les personnes qui le lisent sont des associés, des membres du conseil d’administration et des équipes de négociation qui doivent comprendre le risque en termes financiers.

Un livrable DD technique solide comprend :

• Résumé (1 page) :Recommandation Go/No-Go avec les 3 principaux risques et leur coût de remédiation estimé.
• Registre des risques :Chaque risque est classé par gravité (critique, élevé, moyen, faible) avec une estimation en dollars à corriger et un calendrier à corriger.
• Évaluation de l'évolutivité :L’architecture actuelle peut-elle soutenir le plan de croissance ? Dans la négative, quels changements sont nécessaires et combien coûtent-ils ?
• Feuille de route d'intégration :Un calendrier réaliste pour connecter le produit de la cible à la plateforme de l'acheteur, avec des dépendances et des bloqueurs signalés.
• Bilan de l'équipe :Risques liés aux personnes clés, déficits de compétences et plan de recrutement si la feuille de route post-acquisition nécessite des capacités qui manquent à l'équipe actuelle.
• Forfait 100 jours :Les actions techniques les plus prioritaires au cours des 100 premiers jours suivant la clôture, séquencées par impact et urgence.

Chaque découverte doit être liée aux dollars et au calendrier. "La couverture des tests est de 23%" est une observation. « La couverture des tests est de 23 %, ce qui signifie que chaque nouvelle version de fonctionnalité comporte un risque de régression de 30 à 40 % ; remédier à ce problème pour atteindre une couverture de 70 % prendra 6 à 8 semaines et coûtera entre 40 000 et 60 000 $ » est une intelligence exploitable.

Erreurs courantes commises par les acquéreurs lors du Tech DD

S'appuyer sur les mesures autodéclarées par la cible.Le vendeur affirme qu'il se déploie deux fois par semaine et qu'il dispose d'une couverture de test de 80 %. Vérifiez-le. Extrayez les journaux de déploiement. Exécutez la suite de tests. Les mesures d’ingénierie autodéclarées sont souvent ambitieuses et non réelles.

Confondre « ça marche » avec « c'est bien construit ».Un produit peut générer 10 millions de dollars de revenus tout en fonctionnant sur une base de code dont la maintenance coûtera 3 millions de dollars au cours des trois prochaines années. Un logiciel fonctionnel et un logiciel maintenable sont des choses différentes. DD doit évaluer les deux.

Sauter les entretiens d'équipe.Le code vous indique ce que fait le système aujourd'hui. L'équipe vous indique si le système peut évoluer. Parlez à des ingénieurs individuels, pas au CTO qui présente un diaporama. Demandez-leur : « Que reconstruiriez-vous si vous aviez 3 mois ? » Leurs réponses révèlent la dette technologique avec laquelle ils vivent quotidiennement.

Traiter Tech DD comme une case à cocher.Certaines entreprises embauchent un fournisseur DD, reçoivent le rapport, le déposent et poursuivent la transaction sans modification. Le but de DD est d’informer les termes de la transaction. Si le rapport identifie 1,5 million de dollars de coûts de réhabilitation, ce chiffre devrait apparaître dans la négociation des prix. Si ce n'est pas le cas, vous avez payé le DD et l'avez ensuite ignoré.

L'essentiel

La diligence raisonnable technique n’est pas un exercice de conformité. C'est un outil de valorisation. Les entreprises qui le traitent sérieusement, l'emploient en ingénieurs expérimentés (et non en consultants généralistes), le gèrent tôt dans le processus de transaction et lient chaque conclusion à un montant en dollars, sont celles qui évitent les surprises post-clôture qui détruisent les rendements.

Le coût d’un engagement technique approfondi en matière de DD est de 0,1 à 0,3 % de la valeur de la transaction. Le coût de manquer un risque critique représente 10 à 30 % de la valeur de la transaction. Le calcul est simple.

Questions fréquemment posées