La due diligence financière est rodée. La due diligence juridique aussi. La due diligence technique, elle, reste souvent le parent pauvre du processus : confiée à la dernière minute à des consultants généralistes armés d’une checklist, bouclée en quelques jours, produite sous forme d’un rapport qui rassure sans vraiment éclairer.
C’est une erreur qui a un coût. Pas toujours visible à la signature, mais presque toujours visible à l’intégration, à la première crise de production, ou à la première tentative de changer quelque chose.
Ce qu’est une due diligence technique et qui la commande
Une due diligence technique est une évaluation indépendante de la qualité, de la maturité et des risques d’un système technologique dans le cadre d’une décision d’investissement : acquisition, levée de fonds, fusion, ou prise de participation significative.
Elle répond à une question de fond : est-ce que ce que j’achète vaut ce que je pense acheter, et à quel coût réel ?
Ce n’est pas un audit de sécurité, ni un test d’intrusion. C’est une évaluation multidimensionnelle qui produit une image fidèle de l’état d’un actif technologique, de ses risques cachés, et de ce qu’il faudra investir pour le faire tenir dans la durée.
Qui la commande :
- Des fonds de capital-risque ou de capital-investissement évaluant une cible d’acquisition ou une participation significative, souvent au-dessus de 5 à 10 M€
- Des acquéreurs stratégiques en M&A souhaitant un regard indépendant avant clôture
- Des entreprises se préparant à une levée de fonds qui veulent anticiper les questions des investisseurs (vendor due diligence)
- Des conseils d’administration souhaitant objectiver l’état réel de leur propre actif technologique
Nous sommes régulièrement sollicités par des investisseurs institutionnels (Banque des Territoires (Caisse des Dépôts), CM-CIC Investissement, RATP Capital Innovation, Demeter, entre autres) pour conduire ces évaluations sur des sociétés technologiques et des éditeurs de plateformes SaaS ou mobiles.
Quand elle intervient : idéalement entre la lettre d’intention et la clôture, suffisamment tôt pour peser sur la valorisation ou les conditions de la transaction. Dans la réalité, souvent trop tard pour vraiment changer les termes de l’accord. Une DD technique commandée à J-10 de la clôture produit un rapport, pas une décision éclairée.
Ce qu’une bonne DD technique doit couvrir
Notre méthodologie s’articule autour de trois axes, systématiquement adressés sur chaque mission.
Axe 1 : la conception de la solution
C’est l’évaluation du coeur technique : l’architecture, le code, les composants.
- Validité des choix d’architecture : les décisions structurantes sont-elles justifiées ? L’architecture est-elle adaptée au problème réel, ou surdimensionnée, ou sous-dimensionnée ?
- Modularité et capacité à évoluer : peut-on faire croître le système sans le refaire ? Peut-on isoler et remplacer un composant sans tout arrêter ?
- Statut des briques logicielles et matérielles : quelles dépendances sont EOL ou non maintenues ? Quelles CVE sont ouvertes et exploitables dans ce contexte ?
- Risques cyber : maturité de l’équipe sur les pratiques de sécurité, intégration des référentiels OWASP, qualité du code du point de vue de la sécurité
L’audit de code permet ici d’évaluer la clarté, les bonnes pratiques, la maintenabilité, et la robustesse réelle du système, au-delà de ce que les équipes présentent en démo.
Axe 2 : le pilotage et l’organisation
Un système c’est aussi une organisation. Les risques humains et organisationnels sont souvent sous-estimés dans une DD classique.
- Qualité des processus et de la documentation : le système est-il documenté à un niveau qui permette à un tiers de l’opérer et de l’évolutions sereinement ?
- Organisation des équipes en cohérence avec les objectifs : la structure réelle des équipes sert-elle la roadmap ?
- Concentration du savoir : existe-t-il des bus factors critiques ? Un système maintenu par une seule personne qui détient tout le contexte dans sa tête est un risque réel, souvent invisible dans les slides de présentation.
- Complexité à maintenir par un tiers : l’acquéreur peut-il reprendre le système sans dépendre indéfiniment de l’équipe d’origine ?
Axe 3 : les engagements sur le service
Le troisième axe porte sur la capacité du système à tenir ses engagements en production, dans la durée.
Nous déroulons sur cet axe un questionnaire structuré dérivé de la norme ISO 27001, qui permet d’évaluer :
- L’offre d’hébergement : QoS, GTR, PCA et PRA
- Le niveau de conformité réglementaire : RGPD, exigences sectorielles applicables
- La propriété intellectuelle des composants : les licences sont-elles identifiées ? Des composants tiers exposent-ils à des risques juridiques ?
- Le niveau de confidentialité des données stockées et traitées
- Les procédures de maintenance applicative : sont-elles documentées, testées, opérationnelles ?
Comment se déroule une mission
Pour une structure de moins de 30 personnes, un audit se conduit en trois semaines. Pour des structures plus importantes ou des périmètres plus larges, le calendrier est adapté en conséquence.
Phase 1 : Analyser (deux semaines)
La phase d’analyse combine plusieurs types d’entrées : ateliers avec les équipes (CEO, CTO, PO, développeurs, DevOps selon les sujets), accès au code source et à la documentation, questionnaires techniques.
Les ateliers sont structurés par thème : organisation, architecture technique, hébergement et sécurité, pilotage projet. Chaque atelier implique les interlocuteurs pertinents côté cible.
À la fin de la première semaine, un rapport d’étonnement est présenté oralement à l’investisseur. Il synthétise les premiers éléments recueillis et permet à l’investisseur de formuler des questions complémentaires que nous intégrons dans la deuxième semaine d’analyse. C’est un mécanisme d’ajustement en cours de mission qui distingue un audit sérieux d’une lecture de checklist.
Phase 2 : Restituer (une semaine)
La phase de restitution commence par des Tech Talks : des sessions de validation de la matrice de risques en version provisoire, organisées avec les équipes techniques de la cible. Les risques recensés et les recommandations associées sont passés en revue axe par axe (architecture, organisation, engagements de service). Les équipes auditées peuvent corriger des faits, apporter des éléments de contexte, valider ou contester les recommandations.
Cette validation préalable est importante : elle évite de livrer à l’investisseur un rapport contenant des erreurs factuelles que la cible pourrait contester, et elle améliore la qualité des recommandations en intégrant le contexte que les équipes techniques connaissent et que l’audit ne peut pas toujours observer directement.
La restitution finale est présentée à l’investisseur avec les livrables définitifs.
Ce que produit l’audit
Deux livrables constituent la sortie de chaque mission.
La matrice de risques et recommandations
Pour chaque risque identifié : sa présentation et ses impacts pour l’entreprise, la recommandation associée avec sa faisabilité validée par les équipes auditées, une estimation de charge en jours-homme pour le traiter, et la catégorie du risque (sécurité, bonnes pratiques, propriété intellectuelle, performance, organisation…).
Ce format chiffré est un choix délibéré. Une recommandation sans estimation de charge est une opinion. Une recommandation chiffrée est un outil de décision.
La note de synthèse
Un document qui présente l’avis de l’auditeur sur la capacité de la société à atteindre ses objectifs business, une analyse SWOT de la solution, les éléments de réponse aux questions spécifiques formulées par l’investisseur, et un tableau récapitulatif des risques par catégorie et criticité.
Ce que nous apportons : des praticiens, pas des auditeurs
Notre posture est différente de celle d’un cabinet de conseil généraliste. Nous ne venons pas avec une checklist. Nous venons avec la connaissance de ce que ces systèmes coûtent à maintenir, à faire évoluer et à faire tenir sous pression, parce que c’est notre métier quotidien.
Nous avons modernisé des systèmes legacy dans des environnements critiques : bancaire, assurance, santé, industrie. Nous savons reconnaître un système qui “fonctionne” en démo mais qui va produire 200 jours-homme de remédiation dans les 18 mois. Nous savons aussi distinguer la dette acceptable (un choix conscient, documenté, justifié par des contraintes de délai ou de coût) de la dette dangereuse (le résultat d’une absence de maîtrise).
Nous avons déployé des systèmes en production. La différence entre ce qu’une architecture promet sur le papier et ce qu’elle produit à 3h du matin quand le système monte en charge, nous la connaissons de l’intérieur.
Nous avons mis en place des dispositifs de MCC sur des systèmes critiques. Nous savons ce que ça coûte de maintenir un système en condition de confiance, et nous pouvons évaluer si le système audité est construit pour être maintenu ou pour être jeté dans trois ans.
Cette expérience change la lecture. Elle permet de repérer ce qu’une checklist ne voit pas : les raccourcis qui semblent anodins mais qui bloquent toute évolution, les architectures élégantes sur le papier mais fragiles à l’usage, les documentations qui existent mais qui ne correspondent plus à rien.
Les plateformes auditées sur nos missions passées couvrent des domaines variés : dataviz SaaS, mobilité multi-modes, location de véhicules, smart metering et smart grid, places de marchés dématérialisés, calcul distribué intensif, services d’aide à la personne. Et depuis deux ans, des assistants IA pour les professions réglementées, un domaine où les enjeux de DD sont particulièrement complexes.
Ce que l’audit ouvre, pas seulement ce qu’il ferme
Un point que nous considérons comme un différenciateur réel : les recommandations que nous produisons sont exécutables par nos équipes.
Chaque risque dans la matrice est accompagné d’une charge estimée en jours-homme. Ces charges correspondent à des prestations que nous savons réaliser. L’investisseur qui commande la DD peut, s’il clôture l’opération, solliciter directement les équipes qui ont conduit l’audit pour traiter les points identifiés.
Ce n’est pas systématique, et ce n’est pas une obligation. Mais c’est une option qui change la nature de la DD : elle n’est plus seulement un rapport qui liste les problèmes, elle devient le point de départ d’un plan d’action concret.
L’IA : le nouveau terrain de la DD technique
Depuis 2024, une proportion croissante des cibles que nous évaluons embarquent de l’IA dans leur produit ou leurs opérations. C’est un terrain pour lequel les outils de DD classiques sont structurellement inadaptés.
Ce qu’un système IA ajoute comme dimensions de risque :
La qualité et la gouvernance des données d’entraînement. Un modèle est aussi bon que les données sur lesquelles il a appris. Des données biaisées, incomplètes, ou dont la provenance est juridiquement problématique (droits, RGPD, consentement) constituent un risque réel, souvent invisible dans les démos. Les barrières à l’entrée d’un acteur IA reposent souvent sur la qualité de ses données propriétaires : évaluer cet actif est une question centrale dans la DD d’un éditeur IA.
La maturité LLMOps. Un modèle qui fonctionne en démo n’est pas un système en production. La gestion des prompts, l’évaluation systématique (evals), l’observabilité en production, la gestion du drift de modèle : leur absence est un signe que le système n’a jamais vraiment été industrialisé. Nous distinguons ce qui est un POC habillé de ce qui est un système exploitable.
La conformité AI Act. Pour les systèmes IA à risque élevé (décision de crédit, scoring, santé, emploi…), l’AI Act impose des exigences de traçabilité, de supervision humaine et de documentation. Un système non conforme acheté avant la clôture, c’est un chantier de mise en conformité à absorber après. Nous évaluons ce gap et le chiffrons.
La dépendance aux fournisseurs de modèles. Un système entièrement construit sur l’API d’un fournisseur unique sans couche d’abstraction est exposé aux changements de pricing, aux dépréciations d’API et aux évolutions de comportement lors des mises à jour de modèle. Cette dépendance doit être évaluée et quantifiée.
La barrière à l’entrée réelle. Au-delà des benchmarks que la cible présente, nous évaluons l’avance réelle de la solution par rapport à ce que des concurrents pourraient répliquer à 12 ou 24 mois : complexité des technologies mises en oeuvre, qualité des données propriétaires, profondeur de l’intégration dans les workflows métier des clients.
La confiance au coeur
Ce qui distingue notre approche n’est pas méthodologique. C’est une conviction sur ce que nous faisons quand nous auditons un système.
Nous ne cherchons pas à rassurer. Nous cherchons à produire une image fidèle. Rassurer à la signature pour découvrir les problèmes à l’intégration, c’est rendre un mauvais service à tout le monde.
Nous ne confondons pas complexité et dangerosité. Certains systèmes sont complexes pour de bonnes raisons : règles métier sophistiquées, contraintes temps réel, domaines fortement réglementés. La complexité accidentelle, celle qui ne sert aucun objectif métier et n’est que le sédiment de mauvaises décisions accumulées, c’est différent. Distinguer les deux demande une lecture technique que seuls des praticiens expérimentés peuvent faire.
Nous ne vendons pas de conformité de façade. Un SBOM produit pour cocher une case, une documentation rédigée après coup pour l’audit, des tests ajoutés à la hâte la semaine avant la revue : nous avons appris à les reconnaître. Ce n’est pas ce que nous produisons, et ce n’est pas ce que nous validons.
Vous pilotez un investissement et souhaitez une évaluation technique indépendante ? Parlons de votre contexte.