Due diligence technique avant un rachat : la checklist

Avant de racheter une entreprise dont la valeur repose sur son SI ou sur un logiciel, un repreneur doit vérifier six choses : qui possède réellement le code, quelle dette technique est cachée sous le capot, quels coûts n’apparaissent pas dans les comptes, de quelles personnes ou prestataires uniques l’activité dépend, si la scalabilité promise existe vraiment, et si les données valent ce qu’on vous dit. Le reste est du confort. Ces six thèmes, on les déroule point par point ci-dessous, avec pour chacun la question à poser, le document à exiger, et le drapeau rouge qui doit vous alerter.

Attention à ne pas confondre cet exercice avec le diagnostic technique d’un système qu’on possède déjà. Ici la posture est différente : vous êtes acheteur, le vendeur a intérêt à embellir, et vous n’avez souvent que quelques semaines d’accès limité pour trancher un investissement à plusieurs centaines de milliers d’euros. On regarde donc moins ce qui va bien que ce qui pourrait faire s’effondrer la valeur une fois le chèque signé.

Posture : vous cherchez ce que le vendeur n’a pas envie de montrer

Une fois, en accompagnant un repreneur sur le rachat d’un éditeur de logiciel, le dirigeant vendeur nous répétait que « tout est propre, tout est documenté ». On a demandé une chose simple : reconstruire l’application à partir de zéro sur une machine neuve, devant nous, sans la personne qui la connaissait par cœur. Deux jours plus tard, personne n’y arrivait. Le savoir n’était pas dans le dépôt de code, il était dans la tête d’un développeur qui partait à la retraite trois mois après la vente. La valorisation ne l’avait pas anticipé.

C’est toute la posture de la due diligence technique. Le vendeur ne ment pas forcément, mais il vous montre la version rangée. Votre travail est de tester, pas d’écouter. Chaque point qui suit se vérifie par une preuve, jamais par une déclaration.

Thème 1 : la propriété réelle du code et des actifs

C’est le point qui tue le plus de deals, et le plus souvent négligé.

• La question à poser : qui a écrit chaque brique, et qui en détient les droits aujourd’hui ? Développeurs salariés, freelances, agence, code open source sous licence contraignante ?
• Le document à exiger : les contrats de cession de droits pour chaque prestataire externe, l’inventaire des licences tierces avec leur type (une licence copyleft type GPL sur un composant central peut vous obliger à publier votre code), et l’accès en propre aux dépôts, noms de domaine, comptes d’hébergement et registrars.
• Le drapeau rouge : un freelance a codé le cœur du produit sans contrat de cession signé. Dans ce cas, l’entreprise n’est pas propriétaire de ce qu’elle vend. Autre signal : les noms de domaine ou les comptes cloud sont au nom personnel d’un associé ou d’un « prestataire fantôme » qu’on ne retrouve plus.

Thème 2 : dette technique et bus factor

La dette technique ne se voit pas dans un compte de résultat, mais elle se paie après le rachat, en lenteur et en budget.

• La question à poser : depuis combien de temps le code n’a pas été mis à jour, et combien de personnes sont capables d’y toucher sans casser la production ?
• Le document à exiger : l’historique du dépôt de code (dates de commits, fréquence), la liste des dépendances et de leurs versions, et un organigramme technique honnête. Le « bus factor » est le nombre de personnes qui, si elles disparaissaient demain, emporteraient un savoir irremplaçable. Un bus factor de 1 est un risque majeur.
• Le drapeau rouge : une seule personne comprend l’architecture, aucune documentation, des dépendances abandonnées par leurs éditeurs, et un framework en fin de vie. Vous n’achetez pas un actif, vous achetez un chantier de reconstruction que le prix de vente n’intègre pas.

Thème 3 : les coûts cachés

Le SI coûte toujours plus que la ligne « informatique » du bilan.

• La question à poser : quels abonnements, licences et prestations récurrentes font tourner l’entreprise, et lesquels sont indexés ou renégociables à la hausse ?
• Le document à exiger : la liste exhaustive des abonnements SaaS et cloud avec leur coût mensuel et leur date de renouvellement, l’inventaire des correctifs de sécurité en retard, et le registre RGPD. La dette de sécurité (mots de passe partagés, absence de mises à jour, aucun test de restauration de sauvegarde) est un coût différé qui peut se transformer en incident coûteux.
• Le drapeau rouge : des tarifs éditeurs qui doublent au prochain renouvellement, une facture cloud qui grossit sans que personne ne l’explique, ou l’absence totale de registre des traitements de données. Un défaut RGPD non traité, c’est une amende potentielle qui devient votre problème le jour où vous signez.

Thème 4 : les dépendances critiques

Toute entreprise a des points uniques de défaillance. Il faut les nommer avant, pas après.

• La question à poser : qu’est-ce qui, en une seule panne ou un seul départ, arrête l’activité ?
• Le document à exiger : la cartographie des dépendances (l’homme-clé indispensable, le prestataire unique qui détient les accès, le serveur physique « sous le bureau » sans redondance ni sauvegarde externalisée), et les contrats de maintenance avec leurs clauses de réversibilité.
• Le drapeau rouge : l’application tourne sur une machine unique dans un local non sécurisé, un prestataire exclusif refuse de partager le code source, ou l’homme-clé n’est lié par aucune clause de présence post-acquisition. Chacun de ces points doit devenir une condition de négociation, pas une découverte de l’après-vente.

Thème 5 : la scalabilité réelle contre la scalabilité promise

Le vendeur vous vend une croissance. Vérifiez qu’elle tient techniquement.

• La question à poser : que se passe-t-il si le nombre d’utilisateurs ou de transactions est multiplié par dix ? L’architecture suit, ou elle s’écroule ?
• Le document à exiger : les métriques de charge réelles (temps de réponse aux heures de pointe, saturation des serveurs), les résultats d’éventuels tests de charge, et l’architecture technique décrite noir sur blanc.
• Le drapeau rouge : aucune donnée de performance disponible, une base de données monolithique sans plan de montée en charge, et un discours commercial sur la croissance qui n’est étayé par aucun test. Une promesse de scalabilité sans preuve est une hypothèse, et vous la payez au prix d’une certitude.

Thème 6 : la qualité des données

Pour beaucoup de rachats, la donnée est l’actif principal. Elle est aussi la plus facile à survendre.

• La question à poser : les données sont-elles propres, complètes, exploitables et légalement détenues ?
• Le document à exiger : un échantillon réel de la base (anonymisé si nécessaire), le taux de complétude et de doublons, l’origine du consentement pour les données personnelles, et la documentation du modèle de données.
• Le drapeau rouge : une base client gonflée de doublons et de contacts morts, des données collectées sans base légale claire, ou un modèle de données que personne ne sait expliquer. Vous risquez d’acheter un volume flatteur qui, une fois nettoyé, vaut le tiers de ce qu’on vous a annoncé.

La synthèse qui sert à négocier

À la fin, chaque point se range en trois cases : bloquant (on ne signe pas sans résolution), à provisionner (on ajuste le prix ou on met de l’argent sous séquestre), à surveiller (on documente pour l’après). Ce classement n’est pas un rapport d’audit posé sur une étagère : c’est un levier de négociation. Un bus factor de 1 devient une clause de présence de l’homme-clé. Une dette de sécurité chiffrée devient une baisse de prix. C’est le rôle d’un expert en transition que de traduire ces constats techniques en arguments financiers que le repreneur peut poser sur la table.

Mini-FAQ

Combien de temps prend une due diligence technique ?

En pratique, de quelques jours à deux ou trois semaines selon la complexité du SI et la qualité de l’accès accordé. L’accès limité est la contrainte principale : le vendeur ouvre rarement tout. On priorise donc les six thèmes ci-dessus et on documente ce qu’on n’a pas pu vérifier, car un angle mort déclaré vaut mieux qu’une fausse certitude.

Quelle différence avec un diagnostic technique classique ?

Le diagnostic classique sert le propriétaire d’un système à le faire progresser. La due diligence sert un acheteur à décider s’il signe, et à quel prix. La posture est adverse, le temps est court, et la sortie est une décision d’investissement, pas une feuille de route d’amélioration. C’est le même terrain observé avec des lunettes différentes.

Peut-on faire cette due diligence en interne ?

Si vous avez un profil technique senior disponible et neutre, oui. En pratique, le repreneur est accaparé par la due diligence financière et juridique, et le volet technique passe à la trappe jusqu’au jour où il coûte cher. Un regard externe a aussi l’avantage de poser au vendeur les questions gênantes sans polluer la relation future.

Pour aller plus loin

• Feuille de route stratégique : le cadre qu’on utilise pour transformer les constats en plan d’action post-acquisition
• Notre grille de diagnostic technique en douze points : la version pour un SI que vous possédez déjà
• Expert en transition : l’accompagnement d’un repreneur pendant et après l’opération
• Laurent Tulpan : vingt ans de terrain grands comptes, dont les opérations où la technique change la valorisation