Agence due diligence technique SaaS : auditer un logiciel avant acquisition

Que couvre une due diligence technique SaaS ?

Le périmètre dépend de la transaction, de la taille du produit et des informations accessibles. Une diligence sérieuse n’applique pas exactement la même profondeur à chaque composant. Nous commençons par les hypothèses que la transaction suppose vraies : capacité à servir davantage de clients, intégration au SI de l’acquéreur, maintien de la roadmap, sécurité des données, stabilité du run ou fonctionnement après le départ éventuel de certaines personnes.

L’analyse technique est ensuite construite pour vérifier ces hypothèses. Chaque constat important doit répondre à six questions : qu’avons-nous observé, quelle preuve le confirme, quel risque cela crée, quand ce risque peut-il se matérialiser, que faut-il faire et quel ordre de grandeur d’effort faut-il prévoir ?

La dette technique peut-elle remettre en cause le plan post-acquisition ?

Toutes les applications contiennent de la dette technique. Le véritable problème apparaît lorsque cette dette empêche l’acheteur de réaliser ce qui justifie économiquement l’acquisition. Une dépendance obsolète isolée n’a pas le même impact qu’une architecture incapable de supporter les nouveaux clients prévus dans le business plan.

Nous distinguons la dette gênante, la dette structurante et les travaux susceptibles de consommer une part importante de la roadmap post-closing. Les constats sont reliés à leurs conséquences : évolution ralentie, migration nécessaire, risque opérationnel, dépendance humaine, capacité limitée, coût Cloud, sécurité ou réécriture ciblée.

Comment vérifier que la plateforme peut supporter le plan de croissance ?

La capacité d’un SaaS ne se résume pas au nombre actuel d’utilisateurs. Nous rapprochons architecture, métriques disponibles, bases de données, traitement asynchrone, dépendances externes, coûts Cloud et incidents historiques.

Le but est de déterminer ce qui se passe réellement si le nombre de clients, de données, de transactions ou d’intégrations augmente significativement. Lorsqu’aucun test de charge ou aucune métrique exploitable n’existe, cette absence constitue elle-même une information. Nous distinguons ce qui est démontré, plausible, à tester ou à faire évoluer avant la croissance prévue.

La revue peut s’appuyer sur l’infrastructure et l’exploitation lorsque la disponibilité, les déploiements, la supervision, les sauvegardes ou les coûts d’exploitation conditionnent le scénario d’acquisition.

Que faut-il vérifier sur le Cloud et les coûts d’exploitation ?

Un SaaS peut être fonctionnel tout en possédant une structure de coûts qui se dégrade avec la croissance. Nous analysons les composants d’infrastructure et, lorsque les données sont accessibles, les tendances de consommation utiles à la compréhension du produit.

La question n’est pas seulement le montant AWS ou Azure aujourd’hui. Il faut comprendre quels coûts varient avec le nombre de clients, quelles ressources sont fixes, quels engagements existent et quelles architectures deviendraient coûteuses à grande échelle.

Un cluster surdimensionné peut être optimisable. Une architecture dont chaque nouveau client nécessite une infrastructure dédiée peut représenter un problème économique plus structurel. L’audit de sécurité Cloud peut approfondir les comptes, IAM, réseau, données, secrets, workloads, logs, sauvegardes et pipelines sans recopier toute cette analyse dans la due diligence.

Comment relire la sécurité et la gestion des données avant acquisition ?

Un acquéreur reprend non seulement du code mais aussi la manière dont le produit protège et manipule ses données. La revue rend lisibles l’authentification, les autorisations, les secrets, les comptes administrateurs, les sauvegardes, le chiffrement lorsqu’il est utilisé, la journalisation, les environnements et les principales surfaces exposées.

Nous regardons aussi si l’équipe peut expliquer quelles données sont réellement stockées, où elles vivent, qui peut y accéder et comment elles sont supprimées ou restaurées. Une revendication de conformité ou de certification peut être rapprochée des éléments techniques accessibles, mais Koragence ne délivre pas de certification juridique ou réglementaire.

Les points RGPD, contractuels ou sectoriels doivent être rapprochés des conseils compétents. L’analyse technique identifie les éléments observables et les limites du périmètre, elle ne remplace pas un avis juridique.

Comment vérifier les dépendances et licences du logiciel ?

Un SaaS moderne repose sur des bibliothèques open source, APIs, services Cloud, composants commerciaux, paiements, authentification et autres logiciels tiers. Nous établissons les dépendances qui peuvent affecter le fonctionnement, le coût ou la maintenabilité du produit.

Sur les composants open source, nous pouvons inventorier les licences déclarées ou détectables et faire apparaître les zones nécessitant une revue approfondie. L’analyse technique identifie des composants et signaux, elle ne rend pas d’avis juridique sur la validité d’une licence ou la propriété intellectuelle.

Comment vérifier que le vendeur possède réellement une base reprenable ?

La propriété technique ne se limite pas à disposer d’un repository Git. Le produit peut dépendre de comptes Cloud personnels, d’un domaine enregistré au nom d’un prestataire, d’un outil SaaS administré par un ancien freelance, de certificats, de clés ou d’éléments auxquels la cible n’a pas un contrôle direct.

Nous vérifions la chaîne de contrôle opérationnelle : repository, Cloud, DNS, domaines, comptes tiers, CI/CD, bases, sauvegardes, monitoring et accès critiques. Le but est de déterminer si l’actif peut effectivement être transféré et exploité après la transaction sans dépendre d’une personne extérieure non maîtrisée.

Les contrats de cession de propriété intellectuelle, clauses des prestataires et autres aspects juridiques restent à vérifier séparément par les conseils de la transaction.

Pourquoi l’équipe technique fait-elle partie de la due diligence ?

La valeur technique d’un produit ne se trouve pas uniquement dans le repository. Une architecture complexe peut être maîtrisée si plusieurs personnes comprennent le système, si les procédures sont documentées et si le run peut être repris.

À l’inverse, une base correcte peut devenir risquée lorsque une seule personne possède les accès, connaît le déploiement, comprend la facturation et sait restaurer la production. Nous analysons la concentration de connaissance, les responsabilités, la capacité de remplacement, la documentation et la manière dont les décisions sont prises, sans évaluer individuellement les salariés.

Comment vérifier la capacité réelle de l’équipe à livrer ?

Une roadmap ambitieuse possède peu de valeur si le produit ne peut être livré que rarement ou avec un niveau de régression élevé. Lorsque les éléments sont disponibles, nous relisons l’historique Git, les revues, les tests, la CI/CD, les environnements, les releases, les incidents et l’organisation du backlog.

La question est simple : la vitesse future supposée dans la thèse d’investissement est-elle cohérente avec la capacité de delivery observée ? Une roadmap de trente fonctionnalités n’est pas une preuve. Nous cherchons des signaux reproductibles : cadence, automatisation, maîtrise des releases et capacité à diagnostiquer les problèmes.

Faut-il auditer les fonctions IA d’un SaaS ?

Oui lorsqu’elles constituent une partie significative du produit ou de sa proposition de valeur. La revue distingue ce qui appartient réellement à la cible de ce qui dépend de fournisseurs externes, sans présenter automatiquement l’usage d’un modèle tiers comme un problème.

Selon le contexte, il faut comprendre la dépendance aux fournisseurs, le coût à l’usage, les données envoyées aux modèles, les mécanismes de fallback, la reproductibilité, le monitoring et la part réellement propriétaire de la solution.

Quel rôle jouent les incidents et le support client ?

Le repository ne raconte pas toute l’histoire du produit. Les incidents, tickets support et problèmes récurrents montrent souvent les zones où architecture, UX, performance ou exploitation créent déjà un coût opérationnel.

Lorsque les données sont disponibles et autorisées, nous rapprochons certains constats techniques de la réalité d’exploitation. Un module complexe devient plus important s’il génère aussi une part significative des incidents, tickets ou interventions manuelles.

Quelle différence entre une due diligence technique et une code review ?

Une code review relit principalement la qualité et le fonctionnement d’une base de code. Une due diligence technique doit répondre à une question plus large : que reprend réellement l’acheteur et cette technologie est-elle cohérente avec ce qu’il prévoit d’en faire ?

Elle couvre donc architecture, infrastructure, sécurité, données, déploiement, fournisseurs, équipe, accès, dépendances et capacité de reprise. Le code reste une preuve essentielle, mais il n’est qu’une partie de l’actif technique.

Quelle différence avec l’audit SaaS Koragence ?

L’audit SaaS vise à améliorer un produit que l’entreprise possède déjà. Il aide à décider ce qu’il faut sécuriser, corriger ou moderniser. La due diligence technique intervient avant ou pendant une transaction et rend les risques lisibles pour un acheteur ou un investisseur.

La méthodologie peut partager certains contrôles, mais la restitution est différente. Une due diligence explique l’effet potentiel des constats sur le calendrier post-closing, le besoin d’investissement technique, l’intégration, la continuité et la dépendance à l’équipe existante. Elle ne remplace pas un audit SaaS hors contexte de transaction.

Quels accès faut-il demander au vendeur ?

Le périmètre idéal dépend de la transaction et de la confidentialité. Les éléments utiles peuvent inclure repositories, documentation d’architecture, CI/CD, inventaire Cloud, supervision, rapports de sécurité, dépendances, coûts techniques, roadmap, incidents et organisation de l’équipe.

Nous privilégions les accès read-only, les comptes dédiés, les droits limités dans le temps et la journalisation. Nous ne demandons pas de mot de passe partagé, de compte root, de secret envoyé par email, d’accès production en écriture sans nécessité ni export de données clients brutes sans justification.

Peut-on réaliser la due diligence sous NDA ?

Oui. La mission peut commencer après signature d’un NDA lorsque le vendeur ou l’acheteur l’exige. Les informations consultées restent limitées au périmètre nécessaire et les accès sont organisés selon le principe du moindre privilège.

Les éléments accessibles, les limites de la data room et les personnes autorisées sont définis avant la revue. Koragence ne copie pas automatiquement tout le repository ou toute la data room et n’envoie pas de code confidentiel ou de données clients vers un service externe sans cadre validé.

Comment se déroule une due diligence technique ?

Le déroulé est adapté à la transaction. Nous commençons par la thèse technique de l’acheteur, les hypothèses à vérifier, les interlocuteurs, les accès disponibles et les limites de confidentialité.

Les outils automatiques peuvent accélérer l’inventaire, l’analyse statique, les dépendances, la SBOM, les secrets, le Cloud ou les métriques CI/CD. Ils produisent des signaux ; les constats de due diligence doivent être vérifiés, contextualisés et reliés à un risque réel.

Que doit contenir le rapport de due diligence technique ?

Le livrable ne doit pas être une exportation brute de scanners. Il doit permettre de revenir sur chaque conclusion importante et de comprendre pourquoi elle existe.

Les constats techniques peuvent-ils faire évoluer les conditions d’une transaction ?

Une migration imprévue, une dépendance critique à une personne, un problème de sécurité ou une infrastructure coûteuse peuvent modifier le budget que l’acheteur doit prévoir après l’acquisition.

La due diligence fournit des faits et des estimations qui peuvent ensuite être utilisés par l’acheteur, ses conseils financiers ou juridiques. Koragence ne recommande pas un prix d’acquisition et ne rédige pas les clauses de la transaction.

Que faire lorsque la data room est incomplète ?

Une due diligence ne doit pas masquer les zones qu’elle n’a pas pu vérifier. Si le repository, les métriques de production ou certains comptes ne sont pas accessibles, le rapport distingue ce qui est vérifié, ce qui est déclaré par le vendeur et ce qui reste non vérifié.

Une absence de donnée n’est pas automatiquement la preuve d’un problème. Elle représente néanmoins une limite à la confiance que l’analyse peut accorder à certaines affirmations et doit rester visible dans la restitution.

Peut-on réaliser une due diligence rapidement avant une échéance ?

Oui, mais le périmètre doit être adapté. Une transaction courte ne doit pas conduire à parcourir superficiellement vingt domaines. Il est souvent plus utile de concentrer l’analyse sur architecture principale, code critique, sécurité, dépendances, Cloud, chaîne de déploiement et dépendance aux personnes.

Le calendrier est défini selon le périmètre, le nombre de systèmes, les accès disponibles et l’échéance de la transaction. Nous ne promettons pas un délai universel de 48 heures ou de cinq jours sans avoir cadré la mission.

Buy-side ou vendor due diligence : quelle différence ?

La plupart des missions visées par cette page sont réalisées pour l’acheteur ou l’investisseur. La buy-side due diligence cherche à identifier les risques et travaux qui seront repris après l’acquisition.

Une société qui prépare sa vente peut aussi réaliser une revue en amont pour documenter ses choix, corriger les problèmes évidents et structurer une data room technique plus exploitable. Il s’agit du même besoin technique, avec un point de vue vendeur.

Que se passe-t-il après l’acquisition ?

La due diligence peut rester totalement indépendante de la phase suivante. Si l’acquéreur souhaite poursuivre avec Koragence, les constats peuvent alimenter une mission distincte de reprise technique, sécurisation, migration Cloud, modernisation, DevOps, maintenance ou intégration post-acquisition.

La remédiation n’est jamais présentée comme incluse automatiquement. Cette séparation protège l’indépendance du diagnostic et permet de choisir ensuite la meilleure équipe ou le meilleur périmètre pour exécuter le plan.