Due diligence technique investisseur : Sécurisez vos acquisitions

Vous n’achèteriez pas un bâtiment sans inspection structurelle. Pourtant, chaque semaine, des investisseurs en capital-risque et des PDG acquéreurs concluent des transactions logicielles de plusieurs millions de francs en se basant sur un pitch deck, des comptes de résultats et un pressentiment concernant l’équipe fondatrice. Ce n’est pas investir. C’est jouer à la roulette.

Le processus d’audit technique (TDD) existe précisément parce que les logiciels cachent les choses. Pas toujours volontairement. Parfois, un CTO bien intentionné a créé quelque chose de véritablement ingénieux, mais n’a jamais anticipé ce qui se passerait si dix ingénieurs partaient et que la seule personne qui comprend la couche d’authentification était maintenant chez un concurrent. Parfois, l’“IA propriétaire” est trois scripts Python et un modèle de prompt rassemblés tant bien que mal. Parfois, le diagramme d’architecture dans la salle de données a été créé six pivots de produit auparavant et ne ressemble en rien à ce qui fonctionne réellement en production.

Nous avons vu tout cela. Plus d’une fois.

Chez Z Digital Agency, notre pratique d’audit technique repose sur un principe simple emprunté au marché immobilier américain : nous sommes les inspecteurs pour la technologie. Vous nous appelez avant de signer. Mais aussi après. Il n’est jamais trop tard, jusqu’à…

Le point faible au cœur des fusions-acquisitions

Seulement un PDG sur quatre déclare mener un audit technologique pour la plupart de ses transactions, bien que 74% considèrent la technologie comme un facteur de croissance. L’écart entre ces deux chiffres est l’endroit où la valeur est détruite.

L’audit financier est non négociable. L’examen juridique est la norme. Mais l’examen technique ? Toujours traité comme optionnel par un nombre surprenant d’investisseurs sophistiqués. Le raisonnement tend généralement à être : “notre partenaire a des connaissances techniques” ou “nous avons parlé longuement avec le CTO”. Aucun de ces éléments n’est un audit de code. Aucun d’eux ne détecte une dépendance critique sur une bibliothèque open-source non maintenue avec trois CVE connus. Aucun d’eux ne vous dit que la base de données n’a pas de plan de reprise après sinistre, ou que toute la configuration DevOps est maintenue par une seule personne qui négocie discrètement une sortie.

Une firme de capital-investissement a investi dans une startup technologique de logistique sans inspecter son architecture logicielle et sa base de code. Après l’acquisition, elle a découvert des problèmes graves d’évolutivité et des failles de sécurité qui ont nécessité des millions de francs en frais de correction, retardant considérablement les plans de mise sur le marché et rongeant les rendements projetés.

Ce n’est pas un cas marginal rare. C’est la norme pour les transactions où l’audit technique a été omis.

Ce que couvre réellement un audit technique

L’audit technique n’est pas une revue de code. Ce n’est pas un audit informatique au sens traditionnel. C’est une évaluation structurée et multi-phases de tous les éléments techniques qui sous-tendent la capacité d’une entreprise à fonctionner, à se développer et à réaliser sa feuille de route.

Chez ZDA, notre processus couvre huit domaines d’évaluation distincts, chacun avec sa propre méthodologie, ses outils et ses critères de notation.

Architecture et infrastructure

La première question est toujours : qu’exécutent-ils réellement, et peut-ce survivre à ce qui vient après ? Nous cartographions l’architecture système complète, évaluons les choix de pile technologique par rapport aux normes actuelles, évaluons la configuration de l’infrastructure cloud sur AWS, GCP ou Azure, et examinons spécifiquement les points où le système tombera en panne à mesure qu’il se développe. Une entreprise affirmant qu’elle peut s’adapter à 100 000 utilisateurs simultanés doit le prouver avec une configuration, pas avec de l’assurance.

Nous examinons le risque de blocage des fournisseurs, la conformité en matière de résidence des données pour les réglementations suisses et de l’UE (RGPD, nDSG), la stratégie multi-régions et la structure des coûts. Une facture d’infrastructure de CHF 3 000/mois qui devient CHF 30 000 avec 10x utilisateurs n’est pas une entreprise évolutive.

Analyse de la base de code

C’est ici que se déroule la vraie investigation. En utilisant des outils comme SonarQube, nous extrayons des métriques objectives : complexité cyclomatique, taux de duplication de code, couverture de test, indice de maintenabilité, densité de points faibles de sécurité. Nos points de référence sont spécifiques : une couverture de test inférieure à 50% sur les chemins critiques est un signal d’alerte. Une duplication de code supérieure à 3% indique une équipe qui a livré sans discipline. Un indice de maintenabilité inférieur à 80 signifie que le prochain ingénieur qui touchera à cette base de code passera ses trois premiers mois à la déchiffrer.

Nous examinons également l’historique Git. La qualité des commits en dit plus long que ce que l’équipe révélera. Des commits peu fréquents, pas de stratégie de branchement, absence de registres de révision de code — ce sont des signaux culturels, pas seulement techniques.

Évaluation de la sécurité

Nous effectuons chaque contrôle OWASP Top 10. Vulnérabilités d’injection, authentification compromise, exposition de données sensibles, contrôle d’accès défaillant. Pour les cibles suisses et européennes, la posture de conformité est importante : SOC2, ISO 27001, RGPD et nDSG ont tous des exigences techniques qui existent soit dans la base de code et l’infrastructure, soit elles ne le font pas. Les affirmations de conformité sans preuves sont courantes. Nous vérifiions.

La gestion des secrets est systématiquement l’un des pires domaines que nous trouvons. Les clés API codées en dur dans les référentiels, les identifiants de base de données dans les fichiers d’environnement validés dans le contrôle de version, aucune politique de rotation de certificats. Ce ne sont pas des risques théoriques. Ce sont les points d’entrée pour les violations qui se produisent dans les six mois suivant une acquisition.

DevOps, CI/CD et reprise après sinistre

La maturité du déploiement est l’un des indicateurs les plus clairs de la culture d’ingénierie. Une équipe qui peut déployer en production de manière fiable et fréquente, avec des portes de test automatisées et une capacité de restauration, est une équipe qui peut s’exécuter après l’acquisition. Une équipe déployant via SSH et un script bash maintenu par une seule personne est un passif.

Nous évaluons les objectifs RTO (Recovery Time Objective) et RPO (Recovery Point Objective) par rapport à l’infrastructure de sauvegarde réelle. Le nombre d’entreprises que nous évaluons qui n’ont pas de plan de reprise après sinistre testé — pas seulement non documenté, mais véritablement non testé — est assez constant pour que nous le considérions maintenant comme l’hypothèse par défaut jusqu’à preuve du contraire.

Performance et évolutivité

Les tests de charge révèlent ce que les diagrammes d’architecture dissimulent. Nous établissons des références de performance sur les temps de réponse des API (p50, p95, p99), effectuons des tests de stress pour identifier les points de rupture et examinons spécifiquement les performances de la base de données, y compris les journaux des requêtes lentes, la configuration du pool de connexions et la stratégie d’indexation. Une plateforme SaaS qui fonctionne bien avec 500 utilisateurs et se dégrade de manière catastrophique avec 2 000 a une histoire d’infrastructure qui devrait affecter matériellement votre modèle d’évaluation.

Concentration du risque d’équipe et de connaissances

La question du facteur bus : combien de personnes doivent être frappées par un bus avant que la technologie de cette entreprise ne devienne non maintenable ? Nous cartographions la concentration des connaissances de manière systématique. Si un ingénieur détient la mémoire institutionnelle du système d’authentification, du pipeline de données et du processus de déploiement, cet ingénieur n’est pas un employé senior. C’est un point unique d’échec catastrophique.

Nous évaluons la structure de l’équipe, la distribution des compétences, la maturité de la méthodologie de développement et la qualité de la documentation et du matériel d’intégration. Une base de code qui nécessite des connaissances tribales pour être navigable est une base de code dont la valeur se dégrade au moment où les personnes clés partent.

Faisabilité du produit et de la feuille de route

La feuille de route du pitch deck par rapport à la réalité technique est souvent la comparaison la plus révélatrice que nous effectuons. Nous évaluons les fonctionnalités prévues par rapport à l’architecture actuelle, estimons les efforts honnêtement et identifions où la feuille de route est techniquement réalisable dans le délai indiqué et où elle ne l’est pas. Nous vérifions également la propriété intellectuelle : qui possède réellement le code, quelles licences open-source sont en jeu et si des composants sous licence GPL créent une exposition en aval.

Scoring des risques et planification de la correction

Chaque conclusion alimente une matrice de risque notée par gravité et probabilité. La sortie n’est pas une liste de problèmes. C’est une feuille de route de correction priorisée avec des estimations d’effort, organisée en actions critiques de 90 jours, améliorations de six mois et optimisations architecturales de douze mois. Cela vous donne un résultat direct pour la négociation de l’évaluation et la planification post-acquisition.

Ce que nous avons réellement trouvé : un engagement TDD réel

En 2021, ZDA a mené une évaluation d’audit technique sur une plateforme SaaS de services professionnels suisse avant une décision d’investissement importante. La plateforme gérait des flux de travail sensibles de RH et de conseil, opérait auprès de plusieurs clients d’entreprise et avait été développée par une petite équipe d’ingénieurs expérimentés au cours de plusieurs années.

Le résumé était clair : la base de code était solide dans sa structure et montrait une compétence d’ingénierie véritable, mais elle portait une dette technique significative et plusieurs risques opérationnels qui devaient être traités avant ou immédiatement après la conclusion de toute transaction.

Spécifiquement, nous avons découvert que la page de connexion seule chargeait plus de 7 Mo de JavaScript — une combinaison d’une bibliothèque de rendu PDF de 2,8 Mo, d’un bundle d’application de 2,5 Mo et d’un chunk de fournisseur de 2,2 Mo. Pour les utilisateurs d’entreprise sur les réseaux d’entreprise, cela créait une latence significative. Pas une faille fatale. Mais pas non plus un problème “nous le corrigerons plus tard”, car “plus tard” dans les calendriers d’intégration post-acquisition signifie douze à dix-huit mois.

La pile Node.js et Vue.js de la plateforme était correcte en principe, mais presque chaque dépendance dans le package.json était obsolète d’un à deux ans. L’ORM Sequelize affichait des avertissements d’obsolescence sur les opérateurs basés sur les chaînes — un problème de sécurité connu que la bibliothèque avait déjà résolu dans les versions les plus récentes. La configuration Docker exécutait deux processus dans un seul conteneur, ce qui viole l’hygiène des conteneurs et crée une imprévisibilité dans les environnements de production.

Nous avons également signalé que la documentation des développeurs était insuffisante pour l’intégration. Un nouvel ingénieur rejoignant l’équipe aurait eu besoin de semaines de transfert de connaissances tribales pour devenir productif. Dans un monde où l’intégration nécessite d’ajouter des ingénieurs, c’est un coût caché que la plupart des acheteurs ne quantifient pas.

Les recommandations : mettre à niveau Vue 2 vers Vue 3 avant que la base de code ne devienne véritablement héritée, mettre en œuvre la division du code pour résoudre le problème du bundle JavaScript, établir un pipeline CI/CD pour remplacer l’approche de déploiement manuel existante et migrer de Forever JS vers pm2 en tant que gestionnaire de processus. Aucune de ces mesures n’était insurmontable. Toutes étaient quantifiables. C’est exactement ce qu’un engagement TDD est censé produire.

La décision d’investissement a procédé — avec une image plus claire de ce qui devrait se produire dans les quatre-vingt-dix premiers jours, et une position de négociation fondée sur des données réelles.

Les outils derrière un audit technique professionnel

Notre pile technique pour l’audit n’est pas une liste de contrôle d’outils à la mode. C’est une combinaison délibérée d’analyse automatisée et d’interprétation experte.

SonarQube gère les métriques de qualité du code et l’analyse de la complexité. OWASP ZAP analyse les vulnérabilités de sécurité au niveau de l’application. Snyk et Dependabot examinent les arbres de dépendances à la recherche de CVE connus. Pour l’infrastructure, nous utilisons l’accès direct à la console cloud, combiné à Nessus pour l’analyse des vulnérabilités au niveau du réseau. Les références de performance proviennent de k6 pour les tests de charge et de Google Lighthouse pour les performances frontales. BuiltWith et Wappalyzer aident à identifier la pile technologique réelle de l’extérieur, qui diffère souvent de ce que l’équipe documente en interne.

La couche d’automatisation est également importante. Nos flux de travail n8n gèrent l’admission, l’orchestration d’analyse et l’agrégation des conclusions préliminaires, ce qui permet à nos ingénieurs seniors de consacrer leur temps à l’interprétation et au jugement plutôt qu’à la collecte de données. C’est la seule façon de mener un processus TDD rigoureux au rythme auquel les transactions se déroulent réellement.

Pour les entreprises ayant des produits natifs en IA ou celles revendiquant des capacités IA significatives, nous menons une couche d’évaluation supplémentaire. À mesure que l’intelligence artificielle et l’apprentissage automatique deviennent de plus en plus pertinents, l’évaluation des fondations d’une entreprise pour l’IA est un élément critique de l’évaluation technologique. Nous rencontrons régulièrement des entreprises où “alimenté par l’IA” dans le pitch deck se traduit par un appel d’API tiers avec un modèle de message autour. Ce n’est pas un avantage concurrentiel. Notre expérience approfondie avec les architectures IA d’entreprise, y compris les modèles d’orchestration IA récursifs que nous avons implémentés pour les entreprises suisses gérant des flux de travail IA à grande échelle, nous permet d’évaluer ces affirmations avec la précision qu’elles nécessitent.

La dimension 2026 : l’infrastructure IA comme risque d’acquisition

Le paysage de l’audit technique a évolué. En 2025 et jusqu’en 2026, la sur-déclaration la plus courante que nous rencontrons dans les discours des entreprises technologiques concerne les capacités IA. Comprendre ce que les PME suisses et européennes font réellement avec l’IA par rapport à ce qu’elles prétendent faire est devenu une compétence critique pour tout investisseur de ce marché.

Notre évaluation de l’adoption et de la mise en œuvre de l’IA dans les entreprises suisses montre un motif cohérent : l’écart entre la capacité IA déclarée et la maturité réelle de l’infrastructure IA est significatif. Une entreprise qui a intégré des APIs OpenAI dans un produit est différente d’une entreprise qui a construit des pipelines de formation propriétaires, ajusté les modèles sur des données spécifiques au domaine et développé une propriété intellectuelle défendable. Un engagement TDD qui ne peut pas distinguer entre ces deux situations ne protège pas votre investissement.

Nous évaluons l’infrastructure IA pour l’évolutivité, la qualité des données, la gouvernance des modèles, la trajectoire du coût par inférence, la conformité aux exigences de résidence des données suisses et la profondeur technique de l’équipe qui la construisait. Sur un marché où “entreprise IA” peut signifier n’importe quoi, d’une véritable équipe d’ingénierie ML à un wrapper API sophistiqué, cette distinction est importante.

À quoi ressemble le livrable

Un rapport d’audit technique de ZDA n’est pas un document que vous lisez dans l’avion et que vous classez. C’est un instrument opérationnel.

Le résumé exécutif s’étend sur deux à trois pages : note de risque global sur une échelle de 1 à 25, trois principales conclusions critiques, trois principales recommandations et un investissement de correction estimé. Assez clair pour présenter à un conseil. Assez précis pour négocier.

Le rapport complet couvre les huit phases avec les conclusions classées par gravité, les preuves provenant de nos résultats d’outils, les implications des risques et les étapes de correction. La matrice de risque est visuelle, pondérée par la gravité et directement liée à un plan d’action échelonné organisé comme des priorités de 90 jours, six mois et douze mois.

Nous incluons les diagrammes d’architecture de l’état actuel réel, pas la version idéalisée de la salle de données. Nous incluons les exportations SonarQube, les conclusions de sécurité avec les références CVE et les évaluations d’équipe avec une analyse honnête du facteur bus.

Le processus s’étend généralement sur deux à trois semaines pour une acquisition SaaS standard. Les calendriers accélérés sont possibles. Les phases sautées ne le sont pas.

Vous avez besoin de ceci. Mais vous ne pouvez pas le faire seul.

La modélisation financière, vous pouvez embaucher pour cela. L’examen juridique, vous avez un conseil pour cela. L’audit technique nécessite quelque chose de différent : des ingénieurs qui ont réellement construit les choses qu’ils évaluent, qui comprennent à la fois la réalité technique et les implications commerciales, et qui vous donneront une évaluation écrite et défendable sous pression de temps.

Notre équipe chez ZDA est composée exclusivement d’anciens entrepreneurs et de praticiens seniors. Personne ici n’a seulement lu sur l’architecture de la base de code dans un manuel. La même équipe qui évalue le pipeline CI/CD de votre cible a construit et géré les pipelines CI/CD. Les mêmes ingénieurs qui évaluent votre CRM cible et votre pile technologique d’outils ont évalué, implémenté et intégré les piles technologiques d’entreprise dans des dizaines de mandats de PME suisses.

Ce n’est pas une accréditation. C’est une méthodologie.

Les entreprises qui menent un audit technologique complet sont 28 % plus susceptibles d’atteindre leurs synergies projetées et 32 % plus susceptibles de conserver les talents techniques clés après l’acquisition. Nous ajouterions un point de données supplémentaire de notre propre expérience : les clients qui nous ont appelés avant de signer n’ont jamais eu une crise technique post-acquisition. Ceux qui nous ont appelés après l’ont fréquemment fait.

La conversation est gratuite. Les conséquences de l’ignorer ne le sont pas.

Appelez mieux ZDA.

Z Digital Agency fournit un audit technique pour les investisseurs, les capital-risqueurs et les PDG acquéreurs en Suisse, en France et en Allemagne. Nos évaluations couvrent l’architecture, la qualité du code, la sécurité, l’infrastructure, les performances, le risque d’équipe, la faisabilité du produit et la capacité IA. Contactez-nous pour discuter de votre transaction à venir.