Checklist de due diligence M&A : ce que les auditeurs des acheteurs testent dans les premières 72 heures

Imaginez que vous avez signé la lettre d’intention il y a trois semaines et que la clôture est au calendrier. Votre équipe d’ingénierie est occupée à préparer la data room, votre directeur financier gère les questions financières et vos avocats testent le contrat d’achat. Puis les auditeurs techniques de l’acheteur arrivent pour la due diligence M&A et, en moins de 72 heures, déposent des conclusions qui remettent le prix convenu sur la table.

Cela arrive plus souvent que quiconque ne veut l’admettre, et c’est totalement évitable avec un audit logiciel effectué en temps voulu. Selon l’enquête 2025 M&A Trends Survey de Deloitte, 79% des dirigeants d’entreprises et 87% des dirigeants de private equity s’attendent à une augmentation continue du volume des transactions cette année, ce qui signifie que davantage d’acheteurs effectuent ces audits plus souvent et avec des questions plus pointues. Malheureusement, la plupart des vendeurs apprennent quelles sont ces questions une semaine trop tard.

Nous avons rédigé ce guide car presque toutes les listes de contrôle de due diligence technologique M&A sur Internet ressemblent à une brochure marketing des Big Four : de longues listes, des catégories vagues, et rien sur ce que l’auditeur de l’autre côté de la table ouvre réellement en premier lorsque la data room est lancée. Ce n’est donc pas tant un article qu’un plan de test que l’auditeur technique d’un acheteur exécute réellement pendant ces trois premiers jours, les normes par rapport auxquelles il évalue la cible, et les trois conclusions qui réinitialisent le plus souvent le prix de la transaction.

Si vous êtes le vendeur, lisez ceci comme votre répétition générale. Si vous êtes l’acheteur, lisez-le comme une vérification de bon sens pour savoir si votre propre équipe pose les bonnes questions dans le bon ordre.

Que vérifient les acheteurs M&A lors de la due diligence technique

Voici la réponse directe, car c’est ce que vous cherchiez :

Lors de la due diligence technique, les acheteurs vérifient quatre points, dans cet ordre approximatif : comment la cible développe son logiciel, ce que la cible possède légalement, comment le logiciel est protégé, et à quel point l’architecture est fragile. Tout le reste dans une liste de contrôle de due diligence M&A typique est une preuve à l’appui de ces quatre questions.

Ce qui change cependant la conversation, c’est que l’auditeur n’arrive pas avec un esprit ouvert. Il arrive avec trois normes de référence ouvertes devant lui. La première est le NIST Secure Software Development Framework, qui définit un développement logiciel discipliné. La seconde est le Software Assurance Maturity Model de l’OWASP, qui évalue la maturité de chacune de ces pratiques dans le monde réel. La troisième est la norme ISO/IEC 27001, la norme internationale de gestion de la sécurité de l’information, qui confirme si quelqu’un dans l’entreprise cible est réellement responsable de quoi que ce soit.

Ensemble, ces trois cadres deviennent une feuille de score :

• NIST indique à l’auditeur quoi chercher
• OWASP SAMM mesure la performance de la cible
• ISO 27001 vérifie que quelqu’un est responsable du résultat

Les vendeurs qui entrent dans la due diligence sans savoir qu’ils seront évalués selon ces trois normes sont pris au dépourvu.

Ensemble, ces trois cadres deviennent une feuille de score :

Pourquoi les premières 72 heures de la due diligence M&A décident du nouveau prix

Un processus typique de due diligence M&A dure de 30 à 60 jours. Cependant, les conclusions qui font bouger le prix apparaissent pendant les trois premiers jours. Cela est dû à la façon dont les auditeurs travaillent réellement.

• Le premier jour est le triage des documents.
• Le deuxième jour est l’analyse forensique du code lui-même.
• Le troisième jour est le moment où l’auditeur rencontre le responsable de l’ingénierie pour poser les questions auxquelles les documents n’ont pas pu répondre.

À la fin du troisième jour, l’équipe de transaction de l’acheteur dispose d’une feuille de score préliminaire, et cette feuille de score façonne toutes les conversations qui suivent. Si les premières 72 heures inspirent confiance, le reste de la période de diligence consiste principalement en vérifications. Cependant, si elles créent le doute, le reste est une renégociation.

Il y a trois conclusions, en particulier, que nous voyons réinitialiser le prix presque à chaque fois. Nous y reviendrons en détail, mais voici la version courte. Premièrement, des lacunes dans la propriété réelle du code. Deuxièmement, des enregistrements de modifications qui s’effondrent lorsque vous remontez trois ans en arrière. Troisièmement, des pièces logicielles non documentées dont l’entreprise dépend mais qu’elle ne peut pas se permettre de perdre. Chacune de ces conclusions correspond clairement à l’une des trois normes de référence, et chacune signale à un acheteur que la valorisation affichée peut ne pas survivre au contact de la réalité.

Le plan de test de 72 heures, heure par heure

Voici ce que nous pouvons conclure de notre expérience en conseil de due diligence M&A, exprimé en langage simple que les non-ingénieurs et les auditeurs peuvent comprendre. Pour rédiger le plan suivant, nous avons utilisé à la fois notre expérience de tels projets et la réglementation actuelle.

Heures 0 à 24 : Triage des documents et cartographie des normes

Le premier jour, c’est de la paperasse. L’auditeur veut voir rapidement si la cible dispose des artefacts qu’une organisation logicielle mature devrait avoir sous la main. La liste comprend généralement :

• Politiques de développement
• Registre de propriété intellectuelle
• Liste complète de tous les composants logiciels tiers utilisés par le produit (liste des composants logiciels, ou SBOM)
• Matrice de contrôle d’accès aux dépôts de code
• Les deux derniers rapports de tests d’intrusion
• Historique des incidents de sécurité sur trois ans

L’auditeur ne lit pas encore ces documents en détail. Il vérifie plutôt leur présence et leur fraîcheur. Par exemple, un rapport de pentest datant de 18 mois est un signal jaune, mais aucun rapport de pentest du tout est un signal rouge. Un SBOM généré la semaine dernière, juste pour la data room, signale que personne ne s’est soucié du risque lié aux dépendances jusqu’à présent.

Chaque artefact est ensuite mappé sur les trois normes de référence. NIST regroupe les pratiques en quatre catégories : Préparer l’organisation, Protéger le logiciel, Produire un logiciel bien sécurisé, et Répondre aux vulnérabilités. L’auditeur vérifie dans quels paniers il y a des preuves et dans lesquels il n’y a que des assurances verbales. OWASP SAMM attribue à chaque pratique un score de maturité de 0 à 3. ISO 27001 mappe les politiques sur des contrôles spécifiques de l’Annexe A et demande si elles sont mises en œuvre ou seulement documentées.

À la fin du premier jour, l’auditeur dispose d’une carte thermique. Vert là où la cible est bien préparée, jaune là où les preuves sont minces, rouge là où il n’y a rien du tout. C’est aussi le jour où nos auditeurs ont historiquement détecté les problèmes les plus graves pour nos clients, simplement parce que la carte thermique révèle comment la cible fonctionne réellement en 24 heures, pas en 24 jours.

Heures 24 à 48 : Analyse forensique du code et des dépôts

Le deuxième jour, l’auditeur examine concrètement le code, ou plus précisément, les enregistrements qui l’entourent. L’objectif est de vérifier que ce que l’entreprise prétend posséder correspond à ce qu’indique le référentiel de code.

La première tâche consiste à vérifier qui a écrit quoi. L’auditeur extrait l’historique des commits et rapproche chaque contributeur des accords d’attribution de propriété intellectuelle signés par les employés et les sous-traitants. Par conséquent, si un freelance a contribué de manière significative au produit principal en 2021, mais que l’entreprise ne peut pas produire d’accord signé transférant la propriété, l’acheteur a désormais un problème. Il en va de même pour le code suggéré ou généré par les outils d’IA, ce qui explique pourquoi les acheteurs en 2026 posent soudainement des questions très précises sur la manière dont l’équipe d’ingénierie les utilise.

La deuxième tâche dans une liste de contrôle de due diligence M&A concerne les licences. Le SBOM du premier jour est maintenant comparé au contenu réel de la base de code. L’auditeur recherche deux choses :

• Les composants open source utilisés sous des licences qui contaminent le code propriétaire qui les entoure et peuvent effectivement forcer l’entreprise à publier son propre code source.
• Les bibliothèques commerciales sans licence ou expirées que personne n’a remarquées car le développeur original est parti il y a deux ans.

Une revue de code approfondie met souvent en évidence ces problèmes des semaines avant qu’un auditeur de l’acheteur ne le fasse, c’est pourquoi les vendeurs qui anticipent effectuent leur propre analyse avant l’ouverture de la data room.

La troisième tâche dans la liste de contrôle de due diligence technique de l’auditeur consiste à reconstruire la piste de gestion des changements. Il parcourt le référentiel des trois dernières années et pose une question simple : pour toute modification apportée à la production, puis-je la retracer du ticket original à la pull request, au commit, puis au déploiement ?

Si la réponse est oui pour la plupart des changements, l’entreprise est en bonne voie. Cependant, si la réponse est non, ou s’il y a de grandes lacunes, des force pushes sur la branche principale, ou des commits qui contournent la revue, c’est une constatation que l’acheteur prend très au sérieux.

La quatrième tâche de la due diligence M&A consiste à cartographier les dépendances. L’auditeur recherche les composants dont l’entreprise dépend mais qu’elle ne peut pas remplacer facilement. Ces exemples pourraient être une bibliothèque maintenue par un seul bénévole qui n’a pas contribué depuis deux ans, ou une version d’exécution que le fournisseur a cessé de prendre en charge au dernier trimestre. Ce sont les points de défaillance silencieux qui apparaissent dans les budgets post-fusion comme des surprises à huit chiffres.

Heures 48 à 72 : Validation des processus et des personnes

Le troisième jour est consacré à la journée humaine de la vérification diligente technique. L’auditeur s’assoit, généralement pendant plusieurs heures, avec le responsable de l’ingénierie et une petite poignée de contributeurs seniors. L’objectif est de confirmer que l’image des deux premiers jours correspond à ce que font réellement les personnes qui construisent le logiciel.

La conversation suit un schéma familier. La modélisation des menaces vient en premier car l’auditeur veut savoir si la sécurité est quelque chose que l’équipe intègre dès la conception ou ajoute à la fin. La réponse aux incidents vient ensuite, l’auditeur demandant au responsable de l’ingénierie de décrire le dernier incident grave du début à la fin. La manière dont l’histoire est racontée en révèle plus que n’importe quel document de politique. Vient ensuite le risque lié aux personnes clés, où l’auditeur demande, très poliment, ce qui se passerait si un ingénieur particulier quittait l’entreprise la semaine prochaine. Les réponses honnêtes sont souvent inconfortables.

À la fin du troisième jour, l’auditeur ferme son ordinateur portable, rédige un résumé d’une page pour l’équipe de transaction, et la négociation commence à évoluer en fonction de son contenu.

Constatations de vérification diligente M&A basées sur les normes qui reconfigurent les transactions

Ci-dessous, nous expliquerons les trois constatations les plus courantes des auditeurs qui affectent immédiatement le prix de la transaction. Nous partagerons également des aperçus de notre expérience en conseil en vérification diligente M&A sur la manière de traiter de tels problèmes s’ils surviennent. Cependant, le moyen le plus simple d’éviter les problèmes à ce stade de votre transaction est de réaliser une vérification de votre côté avant l’arrivée de l’équipe de vérification diligente technique de l’acheteur.

Constatation 1 : Lacunes dans la provenance de la propriété intellectuelle

La provenance signifie simplement la preuve de l’origine de quelque chose. Dans la vérification diligente M&A, les lacunes dans la provenance de la propriété intellectuelle signifient que l’entreprise ne peut pas prouver pleinement qu’elle détient le code qu’elle vend.

Cela se manifeste de manières spécifiques :

• Des sous-traitants ayant construit des parties significatives du produit sans signer d’accord d’attribution de propriété intellectuelle.
• Des composants open source utilisés d’une manière qui viole les termes de la licence.
• Du code généré par des outils d’IA sans aucun enregistrement des invites ayant produit quel résultat.
• Du code acquis lors d’une transaction précédente pour lequel personne ne retrouve les documents de transfert originaux.

La pratique PS.3 du NIST SSDF, qui traite de l’archivage et de la protection de chaque version, exige que l’entreprise conserve un enregistrement clair de chaque artefact de chaque version. Le contrôle A.5.32 de l’ISO 27001 exige la protection explicite des droits de propriété intellectuelle. Par conséquent, lorsqu’un auditeur de l’acheteur ne peut pas réconcilier le code avec les contrats, la réponse est prévisible. Les exclusions d’indemnisation dans le contrat d’achat deviennent plus importantes. Les sommes mises sous séquestre augmentent, et dans les cas graves, le prix principal est réduit de 5 % à 15 %, parfois plus si le code contaminé se trouve dans le produit principal.

Pour les vendeurs, c’est la plus facile des trois constatations à corriger à l’avance, mais seulement si vous commencez au moins 60 jours avant l’ouverture de la salle de données.

Constatation 2 : Pistes de gestion des modifications qui ne survivent pas à un examen de trois ans

La deuxième constatation concerne l’histoire de l’entreprise, pas son présent. Les acheteurs veulent examiner le système de contrôle source sur trois ans et voir exactement comment chaque modification apportée en production y est parvenue. Cela inclut qui l’a proposée, qui l’a examinée, qui l’a approuvée et qui l’a déployée.

Lorsque cette piste est solide, l’acheteur est rassuré sur le fait que la culture d’ingénierie est disciplinée et qu’il est peu probable que la base de code contienne des surprises cachées. Cependant, si la piste est incomplète, l’auditeur commence à chercher ce qui d’autre pourrait manquer. Les modèles courants qui échouent à ce test incluent :

• Des déploiements manuels sans ticket correspondant
• Des « force-pushes » qui effacent l’historique
• Des branches qui n’ont jamais été protégées
• Des revues de code effectuées par la même personne qui a écrit le code
• De longues périodes pendant lesquelles rien n’a été enregistré du tout

La pratique PS.1 du NIST SSDF attend un contrôle clair de toutes les formes de code et de la documentation de support. La pratique de construction sécurisée OWASP SAMM attend que chaque modification soit reproductible et traçable. Le contrôle A.8.32 de l’ISO 27001 exige une gestion formelle des modifications. Lorsque les trois sont faibles, l’acheteur répond avec ce qui est essentiellement une prime de risque d’intégration. Une remédiation obligatoire avant clôture, une mise sous séquestre prolongée, ou une partie du prix d’achat déplacée vers un complément de prix différé lié à des améliorations de l’hygiène de l’ingénierie.

C’est la constatation qui surprend le plus d’entreprises, car l’équipe d’ingénierie pense généralement que son hygiène est correcte jusqu’à ce que quelqu’un y jette un œil.

Constatation 3 : Dépendances critiques non documentées

La troisième constatation est la plus coûteuse à corriger après la clôture de la transaction, c’est pourquoi les acheteurs s’en soucient le plus.

Chaque produit logiciel moderne dépend de dizaines ou de centaines de morceaux de code écrits par d’autres personnes. Certains de ces morceaux sont bien entretenus et largement utilisés, et d’autres sont fragiles. Les plus dangereux sont les dépendances sans lesquelles l’entreprise ne peut pas fonctionner, mais que personne dans l’entreprise ne surveille activement. Cela inclut généralement :

• Une bibliothèque maintenue par un bénévole dans un autre pays
• Un microservice qui appelle discrètement le compte cloud personnel d’un développeur
• Un fichier de configuration avec des informations d’identification secrètes qui n’ont pas été renouvelées depuis 2022
• Une tâche planifiée sur un serveur que personne dans l’équipe actuelle n’a configuré

La pratique PW.4 du NIST SSDF exige que l’entreprise ne réutilise que des composants logiciels bien sécurisés. La pratique des dépendances logicielles OWASP SAMM attend une surveillance continue de tout code externe utilisé. Le contrôle A.8.30 de l’ISO 27001 exige une supervision explicite du développement externalisé et du code tiers. Si l’auditeur d’un acheteur trouve une dépendance critique que personne ne peut expliquer, la réponse est rarement une réduction de prix. Au lieu de cela, il s’agit d’un accord de services de transition plus long, de primes de rétention pour les ingénieurs qui comprennent la dépendance, et d’un fonds de réserve mis de côté spécifiquement pour migrer ou remplacer le composant fragile après la clôture.

Une maintenance logicielle continue et régulière est l’assurance la moins chère contre cette constatation, car elle oblige l’entreprise à tenir un inventaire honnête de ce dont dépend réellement son logiciel.

Comment les vendeurs peuvent s'auto-évaluer avant l'arrivée de l'acheteur

Si vous êtes à 30 à 90 jours d’une LOI signée, vous avez encore le temps d’améliorer plus que vous ne le pensez en appliquant le principe simple suivant : soumettez-vous au même plan de test que celui que l’équipe de l’acheteur utilisera sur vous.

Rassemblez les mêmes artefacts, notez-les selon les mêmes normes et comparez vos conclusions aux trois points mentionnés ci-dessus. L’exercice prend environ deux semaines à une petite équipe si tout est en bon état, et quatre à six semaines si ce n’est pas le cas. Selon notre expérience, il existe cinq corrections qui améliorent le score le plus rapidement et le plus significativement.

• Signez des accords d’attribution de propriété intellectuelle avec chaque contractant actif et documentez la chaîne de propriété pour chaque commit.
• Régénérez la liste des composants logiciels (Software Bill of Materials) et conciliez-la avec la base de code, en corrigeant toute violation de licence.
• Activez la protection de branche dans le dépôt principal et exigez que toutes les modifications passent par une revue documentée.
• Inventoriez toutes les dépendances tierces en production et identifiez les trois ou quatre qui présentent le risque le plus élevé.
• Rédigez, en langage clair, ce que ferait l’équipe d’ingénierie si une personne clé partait demain.

Ces corrections ne feront pas disparaître toutes les constatations, mais elles démontreront à l’auditeur de l’acheteur que l’entreprise connaît ses points faibles et les prend au sérieux, ce qui compte souvent plus que les constatations elles-mêmes.

Si vous préférez qu’une équipe indépendante vous évalue avant l’ouverture de la salle de données, c’est exactement le travail que nous accomplissons au sein de notre département d’audit logiciel. Nous utilisons la même grille d’évaluation que celle de l’équipe de l’acheteur, et nous vous donnons dans les deux semaines ce qu’ils communiqueraient à l’acheteur en trois semaines. Alors, contactez-nous dès aujourd’hui, et nous discuterons de la suite.

Pour une présentation plus approfondie du cadre que nous utilisons dans tous nos audits, consultez notre article « Checklist d’audit SDLC : audit du processus de développement logiciel », qui aborde les mêmes points du point de vue de l’équipe de développement. Et rappelez-vous, s’il y a une chose que nous espérons que vous retiendrez de cet article, c’est que l’auditeur de l’acheteur n’essaie pas de vous piéger. Il cherche à confirmer que le prix indiqué dans la lettre d’intention correspond à la réalité interne de l’entreprise. Plus vite vous pourrez le démontrer, plus vite vous conclurez. Plus il a de temps pour examiner, plus il trouve.

FAQ

Que contient une liste de vérification de vérification diligente technique ?

Une liste de vérification de vérification diligente technique couvre quatre domaines :

• Processus de développement logiciel
• Propriété intellectuelle et licences
• Sécurité et gouvernance des données
• Architecture et risque de dépendance

L’auditeur de l’acheteur évalue les preuves de la cible dans chaque domaine par rapport à trois normes de référence : NIST SSDF, OWASP SAMM et ISO 27001. Les éléments spécifiques comprennent le SBOM, les accords d’attribution de propriété intellectuelle, les enregistrements de gestion des modifications sur une période de trois ans, les rapports de pentest, les journaux d’incidents, la matrice de contrôle d’accès et un inventaire des dépendances tierces.

Combien de temps dure la vérification diligente technique M&A ?

Un processus complet de vérification diligente M&A dure généralement de 30 à 60 jours, les transactions plus importantes ou transfrontalières pouvant durer 90 jours ou plus. Cependant, les constatations qui influencent le prix de la transaction sont généralement identifiées dans les premières 72 heures du flux de travail technique, lorsque l’auditeur examine les documents, effectue des analyses médico-légales des dépôts de code et interroge le responsable de l’ingénierie.

Qui effectue la vérification diligente technique M&A ?

Pour les transactions importantes, un cabinet d’audit logiciel externe ou une société de conseil spécialisée en M&A mène généralement le travail technique, avec le soutien du CTO ou du responsable de l’ingénierie de l’acheteur. Pour les transactions plus petites, l’équipe technique interne de l’acheteur s’en charge souvent directement. Les vendeurs engagent de plus en plus leur propre auditeur externe à l’avance pour s’auto-évaluer avant l’arrivée de l’équipe de l’acheteur, ce qui leur donne le temps de corriger les problèmes qui autrement réinitialiseraient le prix.

Quelle est la différence entre un audit SDLC et une vérification diligente technique M&A ?

Un audit SDLC est interne et aide une entreprise à améliorer son propre processus de développement logiciel. Parallèlement, la due diligence technique en cas de fusions-acquisitions est externe et aide un acheteur à déterminer la valeur réelle d’une entreprise cible. Les deux partagent de nombreuses preuves communes, à savoir les référentiels de code, les politiques de développement, les registres de sécurité et les inventaires de dépendances, mais elles posent des questions différentes. L’audit SDLC demande comment améliorer l’équipe, et l’audit fusions-acquisitions demande s’il faut payer le prix fort.

Qu'est-ce que la cyber due diligence en cas de fusions-acquisitions, et en quoi diffère-t-elle de la due diligence technique ?

La cyber due diligence en cas de fusions-acquisitions se concentre spécifiquement sur la posture de cybersécurité, y compris l’historique des violations, la gestion des identités et des accès, la protection des données et la conformité réglementaire. La due diligence technique est plus large et inclut la cyber due diligence comme l’un de ses quatre piliers, aux côtés du processus de développement, de la propriété intellectuelle et de l’architecture. Pour la plupart des acquisitions de logiciels, les deux groupes de travail sont exécutés en parallèle, et les conclusions se recoupent souvent.

Un vendeur peut-il réaliser une auto-évaluation avant le début de la due diligence ?

Oui, et les vendeurs qui le font bien sont nettement mieux positionnés dans les négociations. L’exercice consiste à exécuter le même plan de test que celui de l’équipe de l’acheteur, à noter les résultats par rapport aux normes NIST SSDF, OWASP SAMM et ISO 27001, et à prioriser les correctifs qui comblent les plus grands écarts dans le temps disponible. La période la plus importante est de 60 à 90 jours avant la signature de la lettre d’intention (LOI), car c’est suffisamment de temps pour remédier aux problèmes qui réévaluent le plus souvent les accords.