Un rachat de logiciel se joue sur 40 lignes. Les avez-vous toutes ?
La plupart des due diligences techniques ratent de la même façon : on regarde le code pendant deux jours, puis on découvre six mois après la signature qu'un freelance n'a jamais cédé ses droits ou qu'une sauvegarde n'a jamais été restaurée. Le problème n'est pas la compétence. C'est l'absence de liste.
Voici la checklist que nous utilisons chez ONDEV : 40 points, six piliers, un niveau de gravité pour chacun. Elle sert à l'acquéreur comme au dirigeant qui prépare la vente de son application.
Dans cet article, vous allez découvrir :
- •Les 40 points de contrôle d'une due diligence technique, numérotés et répartis en six piliers : code, sécurité, infrastructure, équipe, juridique et licences, produit
- •Pour chaque point, ce qu'il révèle réellement sur l'actif et son niveau de gravité (bloquant, majeur, mineur)
- •Les 7 points qui, à eux seuls, peuvent faire échouer une acquisition ou diviser un prix par deux
- •Comment exploiter la checklist différemment selon que vous achetez ou que vous vendez
La valeur d'une application se lit dans son code. Pas dans le pitch, pas dans le business plan : dans le dépôt Git, les contrats et les sauvegardes.
Comment lire cette checklist de due diligence
Une due diligence technique n'est pas un audit de code allongé. L'audit regarde la qualité du logiciel ; la due diligence regarde tout ce que l'acquéreur hérite : code, contrats, équipe, infrastructure. Pour le cadre complet (qui la réalise, en combien de temps, à quel prix), notre guide de la due diligence technique pour acquéreurs pose les bases. Cet article est son complément opérationnel.
Chaque point ci-dessous est noté sur trois niveaux :
- •Bloquant : à lui seul, il justifie de suspendre la négociation tant qu'il n'est pas levé. On ne le compense pas par une décote.
- •Majeur : il ne stoppe pas l'opération, mais il entre dans le prix, dans une garantie de passif ou dans une condition suspensive.
- •Mineur : il n'influence pas la décision d'achat, mais il alimente le plan d'intégration des six premiers mois.
Un point peut changer de niveau selon le contexte : un bus factor de 1 est bloquant pour une plateforme à abonnés, majeur pour un outil interne. Nous indiquons le niveau par défaut.
Pilier 1 : le code (points 1 à 8)
Le code est la première chose que l'on regarde, et celle qui cache le moins de surprises fatales. Mais c'est ici qu'on mesure le coût des douze prochains mois.
| # | Ce qu'on vérifie | Ce que ça révèle | Gravité |
|---|---|---|---|
| 1 | Accès complet au dépôt Git avec tout l'historique des commits | Qui a écrit quoi, le rythme réel de développement, les périodes de silence. Un refus d'accès est en soi une réponse | Bloquant si refusé |
| 2 | Couverture des tests automatisés et exécution effective de la suite complète | La capacité à modifier le produit sans régression. Une suite qui ne passe plus est un aveu | Majeur |
| 3 | Build reproductible depuis un poste vierge et pipeline CI/CD fonctionnel | Le logiciel se déploie-t-il sans l'intervention d'une personne précise ? | Majeur |
| 4 | Versions des langages, frameworks et dépendances majeures, avec dates de fin de support | La dette de mise à jour, soit le coût caché de la première année | Majeur |
| 5 | Analyse statique : complexité cyclomatique, duplication, fichiers de plus de 1 000 lignes | Les zones où personne n'ose plus toucher, donc le coût de chaque évolution future | Mineur à majeur |
| 6 | Documentation technique : README, schéma d'architecture, procédure d'installation | Le temps de prise en main d'un nouveau développeur, en jours ou en semaines | Mineur |
| 7 | Code mort, fonctionnalités désactivées par drapeau, branches abandonnées | L'écart entre le produit vendu et le produit réel | Mineur |
| 8 | Proportion de code généré, copié ou vendorisé, avec sa provenance | La qualité réelle de l'équipe et un premier signal de risque de licence | Mineur |
Pilier 2 : la sécurité (points 9 à 15)
Un seul point de ce pilier peut tout arrêter. Un secret dans l'historique Git ne se « nettoie » pas : il a été vu par toute personne ayant eu accès au dépôt, stagiaires et prestataires compris.
| # | Ce qu'on vérifie | Ce que ça révèle | Gravité |
|---|---|---|---|
| 9 | Secrets en clair (clés API, mots de passe, certificats) dans le code ou dans l'historique Git | Toute personne ayant eu accès au dépôt peut encore accéder à la production | Bloquant |
| 10 | Authentification et sessions : algorithme de hachage, MFA, expiration, réinitialisation | Le risque de compromission massive de comptes utilisateurs | Majeur |
| 11 | Vulnérabilités connues dans les dépendances (scan SCA, CVE critiques ouvertes et leur ancienneté) | L'hygiène de maintenance et la surface d'attaque réelle | Majeur |
| 12 | Chiffrement au repos et en transit : TLS, base de données, sauvegardes, fichiers utilisateurs | L'exposition en cas de fuite et la conformité RGPD | Majeur |
| 13 | Gestion des droits : rôles, moindre privilège, comptes administrateurs partagés | Qui peut faire quoi, et si l'on saurait le prouver | Majeur |
| 14 | Historique des incidents de sécurité et rapports de tests d'intrusion | La transparence du vendeur autant que la maturité de l'équipe | Majeur |
| 15 | Journalisation des accès et alerting sur les anomalies | La capacité à détecter une intrusion et à reconstituer ce qui s'est passé | Mineur |
Pilier 3 : l'infrastructure (points 16 à 22)
L'infrastructure révèle le modèle économique réel du produit. Une application dont l'hébergement dévore la marge n'a pas la rentabilité qu'affiche le compte de résultat.
| # | Ce qu'on vérifie | Ce que ça révèle | Gravité |
|---|---|---|---|
| 16 | Inventaire exhaustif des environnements, hébergeurs, services SaaS tiers, DNS et noms de domaine, avec le titulaire de chaque compte | Ce que l'on achète réellement et qui détient les clés | Bloquant si incomplet |
| 17 | Infrastructure décrite en code (Terraform, Docker, scripts) ou configurée à la main | La reproductibilité, ou la dépendance à la mémoire d'une personne | Majeur |
| 18 | Stratégie de sauvegarde avec preuve d'une restauration complète effectuée dans les 12 derniers mois | La probabilité de perdre les données clients un jour | Bloquant si jamais testée |
| 19 | Monitoring en place, disponibilité mesurée, historique des pannes et de leur durée | La fiabilité réelle, à comparer avec la fiabilité promise aux clients | Majeur |
| 20 | Coûts d'hébergement mensuels et leur évolution sur 24 mois rapportée au nombre d'utilisateurs | La marge réelle et la scalabilité économique du produit | Majeur |
| 21 | Dépendances à des services tiers critiques (paiement, email, API externes) et plan de substitution | Le risque de rupture de service et le degré de verrouillage | Mineur à majeur |
| 22 | Capacité de montée en charge : résultats de tests de charge, goulots d'étranglement connus | Le coût d'un passage à l'échelle après l'acquisition | Mineur |
Pilier 4 : l'équipe (points 23 à 28)
On n'achète jamais seulement du code, mais la capacité de le faire évoluer, et elle habite dans quelques têtes. Si elles partent, le code devient un actif en décomposition.
| # | Ce qu'on vérifie | Ce que ça révèle | Gravité |
|---|---|---|---|
| 23 | Bus factor : combien de personnes comprennent réellement le cœur du système | Le risque qu'un seul départ rende le produit immaintenable | Bloquant si une seule personne |
| 24 | Statut de chaque contributeur significatif : salarié, freelance, prestataire, fondateur | Qui détient le savoir, et qui restera après la cession | Majeur |
| 25 | Turnover technique sur 24 mois et motifs de départ | Le climat de l'équipe et la qualité du management technique | Majeur |
| 26 | Processus de développement : revue de code, gestion des tickets, cadence des releases | La maturité et la prévisibilité des livraisons | Mineur |
| 27 | Adéquation entre les compétences présentes et la pile technique réelle, brique par brique | Le coût de recrutement ou de formation à prévoir | Majeur |
| 28 | Rémunérations des profils clés et clauses de rétention existantes | Le budget nécessaire pour les garder douze mois | Mineur |
Pilier 5 : juridique et licences (points 29 à 34)
Le pilier le plus négligé par les équipes techniques, et le plus souvent fatal. Un acquéreur peut vivre avec du code médiocre, pas avec du code qu'il ne possède pas.
| # | Ce qu'on vérifie | Ce que ça révèle | Gravité |
|---|---|---|---|
| 29 | Titularité de la propriété intellectuelle : cession de droits signée par chaque contributeur, freelances et agences inclus | Si le vendeur possède réellement ce qu'il vend | Bloquant |
| 30 | Inventaire des licences open source et compatibilité avec le modèle commercial (GPL, AGPL, autres licences copyleft) | Une obligation potentielle de publier le code source ou d'arrêter la commercialisation | Bloquant si copyleft non maîtrisé |
| 31 | Licences logicielles commerciales et abonnements SaaS : transférabilité, échéances, clauses de changement de contrôle | Les coûts de renouvellement et les blocages au moment du transfert | Majeur |
| 32 | Conformité RGPD : registre des traitements, contrats de sous-traitance, localisation des données, procédure de suppression | Le risque de sanction et l'ampleur de la remédiation | Majeur |
| 33 | Contrats clients : SLA promis, engagements techniques, clauses de réversibilité et de pénalité | Les engagements dont l'acquéreur hérite sans les avoir négociés | Majeur |
| 34 | Dépôt du code (APP, escrow), marques et noms de domaine enregistrés au nom de la société et non du fondateur | Les actifs réellement inclus dans le périmètre de la cession | Mineur |
Pilier 6 : le produit (points 35 à 40)
Le dernier pilier confronte le discours commercial à la réalité technique. C'est ici que l'on découvre que la fonctionnalité phare de la démo est une maquette, ou que la majorité des utilisateurs déclarés ne se connectent plus.
| # | Ce qu'on vérifie | Ce que ça révèle | Gravité |
|---|---|---|---|
| 35 | Correspondance entre la roadmap et les fonctionnalités vendues d'une part, l'état réel du code d'autre part | L'écart entre le discours et la réalité, donc la fiabilité du vendeur | Majeur |
| 36 | Données d'usage réelles extraites de la base : utilisateurs actifs, rétention, fonctionnalités effectivement utilisées | La valeur réellement perçue par les clients, hors chiffres marketing | Majeur |
| 37 | Backlog de bugs ouverts, leur ancienneté, et tickets de support récurrents | La dette fonctionnelle et le niveau de satisfaction client | Mineur |
| 38 | Dette technique chiffrée : estimation en jours-homme du coût de remise à niveau des points majeurs | L'argument de négociation le plus direct sur le prix | Majeur |
| 39 | Dépendance du produit à une source de données ou à un partenaire unique (API, jeu de données, distributeur) | La fragilité du modèle si ce tiers change ses conditions | Majeur |
| 40 | Outils de pilotage : analytics produit, suivi des performances, accessibilité, feuille de route technique écrite | La capacité à piloter le produit dès le lendemain de la reprise | Mineur |
Comment utiliser la checklist selon que vous achetez ou vendez
La même liste sert deux stratégies opposées. Ce qui change, c'est l'ordre et le tempo.
Vous achetez : commencez par les sept bloquants
Avant toute analyse approfondie, traitez les points 1, 9, 16, 18, 23, 29 et 30. Ils se vérifient en quelques jours et décident à eux seuls si l'opération continue. Inutile de payer une analyse statique complète si le vendeur ne possède pas son code. Et exigez des preuves, pas des déclarations : une restauration se regarde en direct.
Ensuite, déroulez les points majeurs pilier par pilier, et chiffrez chacun en jours-homme (point 38). Vous obtenez trois sorties : une liste de conditions suspensives (les bloquants), un montant de décote ou de séquestre (les majeurs) et un plan d'intégration (les mineurs). Notre prestation de due diligence technique livre exactement ces trois documents.
Vous vendez : traitez la liste à l'envers
Côté vendeur, la checklist devient un plan de nettoyage à lancer six à douze mois avant la mise en vente. Commencez par ce qui prend du temps et ne se rattrape pas en urgence : régulariser les cessions de droits (29), sortir les secrets de l'historique Git et les faire tourner (9), tester une restauration complète (18), documenter l'architecture et réduire le bus factor (6 et 23).
Poursuivez par les majeurs qui pèsent sur le multiple : dépendances en fin de support (4), licences incompatibles (30), suite de tests (2). Chaque point résolu avant l'arrivée de l'auditeur de l'acheteur est un argument de négociation que vous lui retirez.
Enfin, constituez un dossier de preuves, un document par point. Un vendeur qui arrive avec ce dossier raccourcit la due diligence et protège son prix.
FAQ : due diligence technique et checklist
Si plusieurs points bloquants des piliers code et infrastructure ressortent, une refonte d'application web planifiée par lots coûte moins cher qu'une décote subie au moment de la signature.
Combien de temps prend une due diligence technique complète sur ces 40 points ?
Quelle différence entre cette checklist et un audit de code ?
Faut-il un avocat pour le pilier juridique et licences ?
Peut-on acheter malgré un point bloquant ?
Que vaut une due diligence réalisée par l'équipe technique de l'acquéreur ?
Conclusion : 40 points, six piliers, aucune surprise après la signature
Une due diligence technique réussie n'est pas celle qui trouve le plus de problèmes, c'est celle qui n'en laisse aucun pour après. Ces 40 points couvrent tout ce qu'un acquéreur hérite : le code, les secrets qu'il contient, les serveurs qui le font tourner, les gens qui le connaissent, les contrats qui le protègent et les clients qui l'utilisent.
Que vous achetiez ou que vous vendiez, le travail est le même. Seul l'ordre change.
Vous préparez une acquisition ou la cession de votre application ? Parlons de votre dossier : nous déroulons ces 40 points avec vous et nous chiffrons chaque risque avant que vous signiez.
