Ressources
Data room technique d'un SaaS : ce que l'acquéreur vérifie et comment préparer les preuves
Data room technique d'un SaaS : ce que l'acquéreur vérifie, les preuves à réunir, les signaux d'alerte et l'index des pièces à préparer avant la due diligence.
Par Corentin Mas, publié le · 24 min de lecture
Base d'expérience : Méthode de revue de plateforme (architecture, sécurité, coûts cloud, chaîne logicielle) et documentation officielle (OWASP, CycloneDX, SPDX, ISO, FinOps Foundation, RGPD, Code de la propriété intellectuelle), sans pratique de fusion-acquisition revendiquée, sans référence client ni retour de mission.
Relecture factuelle : Claude Code (revue indépendante déléguée par Corentin Mas, 28/09/2026), le
La lettre d'intention est signée, l'exclusivité court, la data room doit ouvrir. Un éditeur SaaS peut découvrir à ce moment les pièces techniques attendues : schéma d'architecture, factures cloud, inventaire des licences, historique des incidents, preuve de restauration, contrats des développeurs externes. Ce qui n'existe pas doit alors être reconstitué dans l'urgence, et une pièce manquante peut devenir une question, puis une clause.
Cet article, écrit pour les fondateurs, directeurs techniques et directeurs administratifs et financiers (DAF) d'éditeurs SaaS qui préparent une cession ou une levée de fonds, décrit ce qu'examine une due diligence technique, les pièces et les preuves à réunir, et les signaux d'alerte à traiter avant l'ouverture de la data room. C'est une méthode de revue de plateforme construite à partir de sources publiques : ce n'est ni un guide de négociation ni une méthode de valorisation, et elle ne préjuge pas de l'issue d'une opération.
Faits datés
Cette lecture s'appuie sur ISO/IEC 27001:2022, OWASP ASVS 5.0.0, SPDX (ISO/IEC 5962:2021), CycloneDX 1.7 (ECMA-424), le RGPD et le Code de la propriété intellectuelle ; les pages officielles citées ont été vérifiées le . Versions, durées de support et conditions commerciales évoluent : relisez la version en vigueur avant de vous y fier.
Vérifié le
Ce que l'acquéreur cherche, et à quel moment de l'opération
Le guide « Réussir la reprise et la transmission : le guide complet », publié en avril 2026 sur le site de la Direction générale des entreprises, définit l'audit d'acquisition, ou due diligence, comme « une vérification approfondie menée par le repreneur et ses conseillers ». Il range la « qualité du système d'information » dans le volet opérationnel, à côté des volets financier, juridique et social. Pour un éditeur SaaS, ce volet devient central : le système d'information est le produit.
La due diligence technique répond à cinq questions : le produit fonctionne-t-il comme il est vendu ? Peut-il absorber la croissance du plan d'affaires, et à quel coût d'infrastructure ? Sa sécurité et sa protection des données sont-elles au niveau des clients visés ? La société possède-t-elle son code, et le savoir-faire est-il transmissible ? Combien coûtera ce qu'il faut corriger après l'opération ?
Où elle se place dans l'opération
Bpifrance Création présente la lettre d'intention comme le moyen d'« obtenir une période d'exclusivité pour mener l'audit de la société et émettre une véritable offre » ; la fiche de Service-Public.fr consacrée à la lettre d'intention indique de même qu'elle permet de demander au cédant une période d'exclusivité. Les constats alimentent ensuite le protocole d'accord, qui porte, selon le guide ministériel, le prix, les conditions suspensives, parmi lesquelles « la réalisation d'un audit », et les garanties. La garantie d'actif et de passif « vise à couvrir les risques non identifiés avant la vente mais liés au passé de l'entreprise » : un risque identifié pendant la due diligence a donc vocation à être discuté avant la signature, et la façon de le traiter relève des parties et de leurs conseils. Une levée de fonds peut donner lieu au même exercice, sur un périmètre fixé par l'investisseur.
Où l'examen technique se place dans une opération
Le schéma suit une opération de la lettre d'intention à la réalisation et montre où un constat significatif ouvre une discussion entre les parties.
Schéma défilable horizontalement ; sa version textuelle complète suit.
Lire le schéma sous forme textuelle
- La lettre d'intention ouvre une période d'exclusivité.
- Le vendeur ouvre la data room ; les due diligences financière, juridique, sociale et technique s'appuient sur les pièces qu'elle contient.
- Sans constat significatif, les parties passent au protocole d'accord et à la signature.
- Un constat significatif ouvre d'abord une discussion entre les parties et leurs conseils ; le protocole d'accord vient ensuite.
- Après la réalisation de l'opération, les actions éventuellement convenues sont suivies.
Trois lecteurs des mêmes preuves
| Critère | Questionnaire de sécurité d'un client | Audit de certification ISO/IEC 27001 | Due diligence technique |
|---|---|---|---|
| Qui demande | Le client, avant le contrat | L'organisme de certification | L'acquéreur ou l'investisseur et ses conseils |
| Question posée | Ce fournisseur est-il assez sûr pour moi ? | Le système de management est-il conforme et fonctionne-t-il ? | La technologie peut-elle porter le plan d'affaires, et que coûtera-t-elle ? |
| Périmètre | Le service vendu | Le périmètre certifié | Toute la société : produit, infrastructure, équipe, contrats techniques |
| Questions propres | Localisation des données, sous-traitants, notification | Fonctionnement du système de management dans la durée | Coûts, dette, propriété du code, personnes clés |
Les volets juridique, fiscal, social et financier relèvent d'avocats et d'experts-comptables ; la due diligence technique les recoupe sur des points précis (licences, cessions de droits, sous-traitants) sans les remplacer.
Périmètre du droit
Architecture, passage à l'échelle et dette technique
Une due diligence technique ne relit pas tout le code. Elle cherche où le produit risque de céder quand le plan d'affaires se réalisera, et ce que coûtera la réparation.
Architecture et passage à l'échelle
Le point de départ est un schéma d'architecture daté : composants, flux de données, environnements, dépendances externes (paiement, e-mail, identité, modèles d'IA appelés par API). Un schéma qui date de la dernière levée peut signaler que personne ne le tient à jour. Viennent ensuite trois questions :
- Le modèle de mutualisation. Base partagée filtrée par l'application, schéma ou compte cloud par client : comment l'isolation entre clients est-elle garantie et testée ? Des clients importants ont-ils une instance ou une branche de code spécifique, qui multiplie le coût de maintenance ?
- La composante qui sature la première. Les preuves sont des tests de charge datés avec leurs hypothèses, les marges mesurées sur la base de données, des objectifs de niveau de service (SLO, Service Level Objectives) et la disponibilité mesurée. Une capacité de montée en charge affirmée sans mesure reste une déclaration.
- La dépendance au fournisseur cloud. Des services managés propriétaires ne sont pas un défaut, mais un coût de sortie à connaître ; « Kubernetes cloud-agnostique : choisir et vérifier une plateforme portable, de l'API au test de sortie » détaille comment le vérifier.
Livraison et qualité
La capacité à livrer se mesure dans l'historique de la chaîne d'intégration et de déploiement continus (CI/CD), pas dans un discours. Le programme de recherche DORA (DevOps Research and Assessment, sans lien avec le règlement européen du même nom) retient cinq indicateurs : délai entre le commit et la mise en production, fréquence de déploiement, temps de rétablissement après un déploiement en échec, taux de changements en échec et taux de déploiements imprévus consécutifs à un incident en production. Sa documentation les destine à une application ou un service à la fois. Un ralentissement durable de la cadence peut signaler une dette accumulée.
La revue vérifie aussi que le produit se reconstruit depuis le dépôt, sans poste de développeur particulier, et que les tests automatisés couvrent les parcours qui portent le chiffre d'affaires, comme la facturation et l'authentification.
Dette technique : un registre, pas un aveu
Nier la dette n'est pas crédible ; la chiffrer l'est. Un registre utile donne, par élément, le composant, le risque, l'effort estimé et l'échéance. Exemples de postes :
- Les versions hors support : langages, frameworks, bases de données, orchestrateur. Sur Amazon EKS, une version mineure de Kubernetes reste 14 mois en support standard, puis 12 mois en support étendu facturé en supplément, avant une mise à jour automatique du seul plan de contrôle. « Support étendu EKS et RDS : calendrier de fin 2026, tarifs et calcul de l'exposition » donne la méthode de calcul.
- Les dépendances abandonnées et les copies divergentes (forks) de projets open source jamais réintégrées.
- Les briques maison qui reproduisent un service standard et qu'une seule personne comprend.
Sécurité, données personnelles, incidents et continuité
Des preuves datées, pas des déclarations
La sécurité se lit à quatre niveaux de preuve. Une déclaration affirme sans pièce (« les accès à privilèges sont revus chaque trimestre »). Un document décrit, daté et attribué (la procédure de revue des accès). Un test démontre par une exécution datée et son résultat (le compte rendu de la dernière revue, avec les comptes retirés). Une attestation est un document établi par un tiers indépendant, qui se lit avec son périmètre et sa période. La revue attend une politique et une analyse de risques datées, le compte rendu de la dernière revue des accès à privilèges, l'authentification multifacteur imposée partout, outils de support compris, une gestion des vulnérabilités avec des délais par sévérité, une journalisation exploitée, et les résultats de tests de sécurité récents avec les corrections associées.
En sécurité applicative, l'OWASP fournit deux grilles publiques. L'ASVS (Application Security Verification Standard), dont la version 5.0.0 date de mai 2025, décrit des exigences de vérification réparties en trois niveaux. Comme les identifiants d'exigence peuvent changer d'une version à l'autre, l'ASVS recommande de les citer avec leur version, par exemple v5.0.0-1.2.5. Il porte sur le produit lui-même : la chaîne CI/CD et les sauvegardes gérées hors de l'application sortent de son périmètre, comme la propriété du code ou l'organisation. SAMM (Software Assurance Maturity Model) évalue la maturité du processus de développement sur cinq fonctions (gouvernance, conception, implémentation, vérification, opérations) et quinze pratiques. Une auto-évaluation datée contre un niveau de l'ASVS, écarts compris, vaut davantage qu'une affirmation générale.
Un certificat ISO/IEC 27001 se lit par son périmètre : s'il exclut la plateforme produit, il ne répond pas à la question. Il se vérifie dans IAF CertSearch, la base mondiale des certifications accréditées. Un rapport SOC 2 est une attestation, pas une certification : le type 1 porte sur la conception des contrôles à une date ; le type 2 porte aussi sur leur efficacité de fonctionnement sur une période. Pour situer ces deux référentiels : « SOC 2 ou ISO 27001 : lequel choisir pour un SaaS français, et comment préparer un premier SOC 2 ».
Certification
Données personnelles
Un éditeur SaaS B2B peut être sous-traitant, au sens du règlement général sur la protection des données (RGPD), pour les données de ses clients, et responsable de traitement pour les siennes ; la qualification de chaque traitement relève de son conseil juridique. La revue vérifie :
- le registre des activités de traitement tenu comme sous-traitant (article 30, paragraphe 2) ;
- les contrats de sous-traitance signés avec les clients (article 28) et la liste des sous-traitants ultérieurs : le sous-traitant n'en recrute aucun « sans l'autorisation écrite préalable, spécifique ou générale, du responsable du traitement » (article 28, paragraphe 2) ;
- les transferts hors de l'Union et leur fondement (chapitre V) ;
- les analyses d'impact, lorsqu'un traitement est susceptible d'engendrer un risque élevé (article 35).
Un signal d'alerte possible : un flux de données vers un outil d'analyse, de support ou un fournisseur de modèle d'IA absent de la liste des sous-traitants.
Historique des incidents
Le responsable de traitement « documente toute violation de données à caractère personnel » (article 33, paragraphe 5), et le sous-traitant lui notifie toute violation « dans les meilleurs délais » (paragraphe 2). L'acquéreur peut demander ces traces, et plus largement le registre des incidents et leurs analyses. Il y lit la fréquence, les causes qui se répètent, la clôture des actions correctives. Un registre vide ne rassure pas : il peut signaler une absence de détection ou de documentation.
Continuité et restauration
Des sauvegardes au vert ne prouvent pas qu'on sait restaurer. La pièce attendue est le compte rendu daté d'une restauration : durée de restauration mesurée, âge de la donnée récupérée, écarts. Autre question : les copies survivent-elles à un compte d'administration compromis ? Un plan de continuité se juge sur ses tests, pas sur sa rédaction.
Coûts cloud, propriété du code et personnes clés
Coûts cloud et engagements
Pour un SaaS, la facture cloud est un coût direct de production qui pèse sur la marge. La revue attend une facture réconciliée sur la période, pas un total de console ; méthode dans « Coût facturé, coût amorti, crédits : réconcilier des montants AWS qui ne tombent jamais juste ».
La question décisive est le coût unitaire. La FinOps Foundation le traite dans sa capacité « Unit Economics », avec des métriques comme le coût par client, par locataire (tenant), par transaction, le coût de service ou le coût par jeton pour les fonctions d'IA. L'acquéreur peut comparer la trajectoire de ce coût à celle du revenu par client : c'est elle qui dit si la marge tiendra à l'échelle. Une dépense non allouée, faute d'étiquetage, rend cette lecture impossible. « FinOps, c'est quoi ? Définition 2026, méthode et par où commencer » pose la méthode.
Les engagements survivent à l'opération. Un Savings Plan AWS engage une dépense horaire sur un ou trois ans et ne se restitue que dans des conditions étroites : achat depuis sept jours au plus, dans le même mois calendaire, engagement horaire de 100 dollars ou moins. S'y ajoutent les remises négociées contre un engagement de dépense et les abonnements annuels d'observabilité ou de sécurité. Un engagement pluriannuel dimensionné sur une croissance que le plan ne prévoit plus pèse comme une dette.
Chiffrage fondé sur vos données
Propriété du code
Pour les salariés, l'article L113-9 du Code de la propriété intellectuelle dévolue à l'employeur les droits patrimoniaux sur les logiciels créés « dans l'exercice de leurs fonctions ou d'après les instructions de leur employeur », sauf dispositions statutaires ou stipulations contraires. Pour un indépendant, l'article L111-1 dispose que le contrat de louage d'ouvrage ou de service « n'emporte pas dérogation » aux droits de l'auteur ; une agence ou une entreprise de services du numérique (ESN) détient, elle, les droits de ses propres salariés. L'Agence pour la protection des programmes rappelle qu'à défaut de cession, le prestataire reste titulaire des droits. Le code écrit par un fondateur avant la création de la société pose une question du même ordre. Ces situations sont des points à faire examiner par un avocat, pas des conclusions de la revue technique.
La vérification technique liste les contributeurs et leur statut sur toute la vie du dépôt ; la qualification des contrats revient au conseil juridique. Elle vérifie aussi que les actifs techniques sont au nom de la société : organisation du gestionnaire de code, comptes cloud, noms de domaine, comptes des magasins d'applications, clés de signature.
Licences open source
L'inventaire part d'un SBOM (Software Bill of Materials), nomenclature des composants logiciels, dans l'un des deux formats normalisés : SPDX, dont la version 2.2.1 a été publiée comme norme ISO/IEC 5962:2021, ou CycloneDX, normalisé sous la référence ECMA-424, dont la version 1.7 correspond à la deuxième édition d'ECMA-424 (décembre 2025). Un SBOM est une pièce d'inventaire : il ne prouve à lui seul ni la titularité des droits ni l'absence de vulnérabilités. Les licences s'y notent par leurs identifiants SPDX, comme Apache-2.0 ou AGPL-3.0-only. Trois cas demandent une lecture attentive, et un examen par un avocat :
- L'AGPL-3.0. Son article 13 impose, si le programme est modifié, d'offrir le code source correspondant à tous les utilisateurs qui interagissent avec lui à distance par un réseau : un composant AGPL modifié au cœur du service peut obliger à publier ces modifications.
- La GPL dans une version distribuée. Le texte de la GPL-3.0 précise qu'une simple interaction avec un utilisateur par un réseau, sans transfert de copie, n'est pas une transmission (« conveying ») ; la Free Software Foundation rappelle que la GPL n'oblige donc pas à publier des modifications exécutées sur un serveur. Mais remettre une copie, comme une version installée chez le client, un agent, une application mobile ou du code JavaScript envoyé au navigateur, constitue en principe une transmission au sens de la licence, et ses obligations peuvent alors s'appliquer ; leur portée relève de l'avocat.
- Les licences qui ne sont pas open source. La
BUSL-1.1figure dans la liste SPDX sans approbation de l'OSI (Open Source Initiative) ; son texte se déclare lui-même « not an Open Source license » et réserve l'usage en production à une autorisation complémentaire du concédant. HashiCorp l'a annoncée le 10 août 2023 pour les versions futures de ses produits, en interdisant leur usage dans une offre concurrente.
Trivy classe les licences selon la classification de Google (forbidden, restricted, reciprocal, notice, permissive, unencumbered, plus unknown pour les licences non reconnues), que sa documentation présente comme une vue « opinionated » du risque : c'est un premier tri, pas une qualification juridique. ISO/IEC 5230:2020 (OpenChain) fixe les exigences d'un programme de conformité des licences ; le SBOM rattaché à l'artefact livré est détaillé dans « DevSecOps en pratique : scanner, signer et promouvoir l'image qu'on déploie vraiment ».
Personnes clés
Une personne qui concentre l'essentiel des commits d'un module critique, les accès d'administration et les gardes d'exploitation est un risque de continuité après l'opération. L'historique Git le mesure ; ces commandes servent aussi au vendeur, avant l'ouverture de la data room :
# Commits par auteur sur douze mois (HEAD évite la lecture de l'entrée standard)
git shortlog -sn --no-merges --since="12 months ago" HEAD
# Auteurs d'un répertoire critique, exemple : la facturation
git log --no-merges --since="12 months ago" --format='%an' -- src/billing | sort | uniq -c | sort -rn
# Secrets présents dans l'historique Git (Gitleaks 8.19.0 et suivantes)
gitleaks git --redact --report-format json --report-path gitleaks.json .
# SBOM du dépôt au format CycloneDX, puis inventaire des licences
syft . -o cyclonedx-json=./sbom.cdx.json
trivy fs --scanners license .Le rapport de Gitleaks est une pièce sensible : un secret trouvé se révoque avant d'être documenté. Face à une concentration forte, un transfert documenté (dossiers d'exploitation, binômes, accès répartis) vaut mieux qu'une promesse ; la rétention se négocie entre les parties.
Côté vendeur : l'index de la data room et les signaux d'alerte
La préparation qui suit applique à la data room la grille d'une revue de plateforme : architecture, sécurité, coûts cloud, chaîne logicielle. Mêmes pièces qu'une due diligence technique, même exigence de date et de preuve ; elle ne remplace ni l'analyse des conseils de l'acquéreur ni celle des vôtres.
La liste de contrôle
| Dossier | Pièces à réunir | Sert aussi à |
|---|---|---|
| Architecture | Schéma daté des composants et des flux ; inventaire des environnements ; modèle de mutualisation ; dépendances externes | Questionnaires clients ; ISO/IEC 27001 |
| Livraison et dette | Description de la chaîne CI/CD ; indicateurs de livraison mesurés ; registre de dette chiffré ; inventaire des versions et fins de support | ISO/IEC 27001 |
| Coûts cloud | Factures et export de coûts réconciliés ; coût unitaire ; engagements en cours et échéances ; abonnements logiciels | Pilotage FinOps |
| Sécurité | Politique, analyse de risques, revue des accès datée, gestion des vulnérabilités, auto-évaluation ASVS ; certificat ISO/IEC 27001 et périmètre, rapport SOC 2 s'il existe ; résultats de tests de sécurité récents et corrections associées | Questionnaires clients ; ISO/IEC 27001 |
| Données personnelles | Registre des traitements, modèle de contrat de sous-traitance, liste des sous-traitants ultérieurs, transferts hors UE, analyses d'impact | Questionnaires clients ; contrats clients |
| Incidents | Registre des incidents, analyses après incident, violations documentées et notifications | Questionnaires clients ; ISO/IEC 27001 |
| Continuité | Plan de continuité, objectifs de durée de restauration et de perte de données, comptes rendus datés de restauration | Questionnaires clients ; ISO/IEC 27001 |
| Propriété et licences | Contributeurs et statut ; cessions de droits des prestataires ; SBOM ; inventaire des licences ; comptes et domaines au nom de la société | Clients qui exigent un SBOM |
| Équipe | Organigramme technique, carte des savoirs critiques, organisation des gardes, accès d'administration par personne | ISO/IEC 27001 |
Chaque pièce se transmet filtrée, datée et légendée ; les plus sensibles se consultent sur place ou dans un espace à accès restreint.
L'index de la data room
Une liste de pièces ne dit pas ce que chacune prouve. L'index de la data room technique le dit, ligne par ligne : le document attendu, la question qu'il éclaire, son propriétaire, sa version et sa date, son périmètre, l'accès autorisé, la preuve disponible et sa nature (déclaration, document, test ou attestation), sa limite et l'action qui en découle. Les inconnues y figurent comme des lignes à part entière, et un risque accepté y porte le nom de la personne qui l'a accepté et sa date de revue.
Exemple fictif. Deux lignes de l'index d'une société imaginaire, sans aucune pièce réelle.
| Champ de l'index | Ligne 1 : restauration de la base | Ligne 2 : licences des dépendances |
|---|---|---|
| Document attendu | Compte rendu du dernier test de restauration de la base principale | SBOM du produit livré et inventaire des licences |
| Question qu'il éclaire | Les données survivent-elles à une panne ou à une erreur, et en combien de temps ? | Le produit embarque-t-il une licence qui impose de publier du code ou qui restreint l'usage ? |
| Propriétaire | Responsable plateforme | Directeur technique |
| Version et date | Version et date du test portées sur le compte rendu | Généré à chaque livraison, rattaché au numéro de version du produit |
| Périmètre | Base de production principale, hors stockage de fichiers | Dépôt principal et image livrée, hors application mobile |
| Accès autorisé | Acquéreur et conseils techniques, après accord de confidentialité | Acquéreur, conseils techniques et juridiques |
| Preuve disponible et nature | Test : restauration exécutée, durée et âge des données mesurés | Document : inventaire produit par un outil, sans qualification juridique |
| Limite | Un seul scénario testé, aucun test depuis un compte d'administration compromis | Licences détectées automatiquement ; composants à licence inconnue non qualifiés |
| Action | Tester le scénario du compte compromis avant l'ouverture | Faire examiner par un avocat les composants AGPL et à licence inconnue |
Les signaux d'alerte
| Signal | Ce qu'il met en jeu | Ce que le vendeur peut préparer |
|---|---|---|
| Code écrit par des prestataires sans cession de droits | La propriété de l'actif principal | Liste des contributeurs et des contrats, à faire examiner par un avocat avant l'ouverture |
| Composant AGPL modifié dans le service, usage contraire à une licence qui n'est pas open source | Une obligation de publier du code, un usage interdit | Inventaire daté, avis d'un avocat, plan de remplacement daté si nécessaire |
| Sauvegardes jamais restaurées, copies à portée d'un administrateur | La survie des données | Test de restauration daté, copies isolées des comptes d'administration courants |
| Violation non documentée, sous-traitants non déclarés | Un risque réglementaire et contractuel | Registre des incidents à jour, liste des sous-traitants complétée, avis du conseil juridique |
| Coût unitaire qui augmente avec le nombre de clients, engagement surdimensionné | La marge et la trésorerie | Coût unitaire mesuré sur plusieurs mois, explication des écarts, échéancier des engagements |
| Savoir et accès concentrés sur une personne | La continuité après l'opération | Transfert documenté, binômes, accès répartis |
| Instances ou branches de code propres à certains clients | Le coût de maintenance | Inventaire des écarts et plan de convergence daté |
Ces signaux ne valent pas conclusion : leur portée dépend de l'opération, et la façon de les traiter dans la négociation relève des parties et de leurs conseils.
Exemple d'organisation en quatre semaines
Cette séquence est un exemple d'organisation, pas une durée garantie de préparation complète :
- Inventaire. La liste ci-dessus, un propriétaire par dossier, un état par pièce : existe, à dater, à produire. Au nom de qui sont les comptes, les domaines, les dépôts ?
- Preuves datées. Revue des accès, test de restauration, export de coûts réconcilié, SBOM, inventaire des licences, recherche de secrets.
- Écarts. Pour chaque manque : état actuel, mesure compensatoire, cible, date, responsable ; le registre de dette reçoit ses estimations, l'index ses limites et ses risques acceptés.
- Relecture croisée. Relire la data room comme l'acquéreur : cohérence avec le plan d'affaires, niveau de diffusion de chaque pièce.
Cette séquence suppose que les pièces existent. Si aucune restauration n'a été testée ou si aucune cession de droits n'a été signée, c'est ce travail de fond qui fixe le calendrier : mieux vaut le mener avant la lettre d'intention. Le même dossier servira au prochain questionnaire d'un client et au prochain audit ISO/IEC 27001.
Pour faire relire la plateforme avant d'ouvrir la data room, ou pour obtenir un avis technique hiérarchisé dans le cadre d'une opération, la page Due diligence technique logiciel & SaaS décrit notre cadre d'intervention : questions, accès et destinataires fixés par une lettre de mission.
Sources officielles et limites de lecture
À la date du , les textes, normes et documentations cités ont été relus sur les sources listées ci-dessous. Quatre limites s'appliquent.
- Le guide ministériel et la fiche Service-Public.fr visent la reprise d'entreprise en général. Lettre d'intention, protocole, conditions et garanties se retrouvent dans une opération sur un éditeur SaaS, avec une structure propre à chacune.
- Aucune durée, aucun prix, aucune décote type. Chaque opération fixe les siens ; la séquence en quatre semaines n'est qu'un exemple d'organisation.
- La lecture des licences et des contrats est technique. Elle repère les cas à examiner ; la qualification revient à un avocat.
- Une data room complète ne garantit ni l'issue de l'opération ni ses conditions. Elle rend les constats vérifiables ; la décision appartient aux parties.
Sources
- Réussir la reprise et la transmission : le guide complet (avril 2026), Direction générale des entreprises, https://www.entreprises.gouv.fr/files/files/Publications/2026/guides/guide-reussir-reprise-transmission.pdf, pages 45, 47, 48, 50 à 52, consulté le 07/10/2026.
- Audit d'acquisition : à quoi sert la lettre d'intention ?, Bpifrance Création, https://bpifrance-creation.fr/moments-de-vie/audit-dacquisition-a-quoi-sert-lettre-dintention, consulté le 07/10/2026.
- Reprise d'entreprise : rédiger la lettre d'intention, fiche F36117, Service-Public.fr, https://entreprendre.service-public.gouv.fr/vosdroits/F36117, consulté le 07/10/2026.
- Règlement européen sur la protection des données, chapitre IV (articles 28, 30, 33 et 35), CNIL, https://www.cnil.fr/fr/reglement-europeen-protection-donnees/chapitre4, consulté le 07/10/2026.
- Règlement européen sur la protection des données, chapitre V (transferts), CNIL, https://www.cnil.fr/fr/reglement-europeen-protection-donnees/chapitre5, consulté le 07/10/2026.
- Code de la propriété intellectuelle, article L113-9, Légifrance, https://www.legifrance.gouv.fr/codes/article_lc/LEGIARTI000039279818, consulté le 07/10/2026.
- Code de la propriété intellectuelle, article L111-1, Légifrance, https://www.legifrance.gouv.fr/codes/article_lc/LEGIARTI000042814694, consulté le 07/10/2026.
- La titularité des droits en droit spécifique des logiciels, Agence pour la protection des programmes, https://www.app.asso.fr/centre-information/base-de-connaissances/code-logiciels/la-titularite-des-droits/en-droit-specifique-des-logiciels, consulté le 07/10/2026.
- ISO/IEC 27001:2022, Information security management systems, Requirements, ISO, https://www.iso.org/standard/27001, consulté le 07/10/2026.
- ISO/IEC 5230:2020, Information technology, OpenChain Specification, ISO, https://www.iso.org/standard/81039.html, consulté le 07/10/2026.
- OpenChain ISO/IEC 5230, License Compliance, OpenChain Project, https://openchainproject.org/license-compliance, consulté le 07/10/2026.
- IAF CertSearch, International Accreditation Forum, https://www.iafcertsearch.org/, consulté le 07/10/2026.
- System and Organization Controls: SOC Suite of Services, AICPA & CIMA, https://www.aicpa-cima.com/resources/landing/system-and-organization-controls-soc-suite-of-services, consulté le 07/10/2026.
- Explaining the 3 faces of SOC, Journal of Accountancy (AICPA), https://www.journalofaccountancy.com/newsletters/2016/jun/3-face-of-soc/, consulté le 07/10/2026.
- OWASP Application Security Verification Standard, dépôt officiel OWASP/ASVS (version stable 5.0.0), https://github.com/OWASP/ASVS, consulté le 07/10/2026.
- What is the ASVS?, ASVS 5.0, niveaux de vérification et format de référence des exigences, dépôt OWASP/ASVS, https://github.com/OWASP/ASVS/blob/master/5.0/en/0x03-What-is-the-ASVS.md, consulté le 07/10/2026.
- OWASP SAMM, modèle de référence (fonctions et pratiques), dépôt officiel owaspsamm/core, https://github.com/owaspsamm/core, consulté le 07/10/2026.
- DORA's software delivery performance metrics (mise à jour du 5 janvier 2026), DORA, https://dora.dev/guides/dora-metrics/, consulté le 07/10/2026.
- Understand the Kubernetes version lifecycle on EKS, AWS, https://docs.aws.amazon.com/eks/latest/userguide/kubernetes-versions.html, consulté le 07/10/2026.
- Unit Economics, FinOps Framework, FinOps Foundation, https://www.finops.org/framework/capabilities/unit-economics/, consulté le 07/10/2026.
- Compute Savings Plans, AWS, https://aws.amazon.com/savingsplans/compute-pricing/, consulté le 07/10/2026.
- Returning a purchased Savings Plan, AWS, https://docs.aws.amazon.com/savingsplans/latest/userguide/return-sp.html, consulté le 07/10/2026.
- Spécification SPDX, historique de la normalisation ISO/IEC 5962:2021, dépôt officiel spdx/spdx-spec, https://github.com/spdx/spdx-spec, consulté le 07/10/2026.
- SPDX License List, données de la version 3.29.0, dépôt officiel spdx/license-list-data, https://github.com/spdx/license-list-data, consulté le 07/10/2026.
- GNU Affero General Public License v3.0 only, texte de la licence, dépôt officiel spdx/license-list-XML, https://github.com/spdx/license-list-XML/blob/main/src/AGPL-3.0-only.xml, consulté le 07/10/2026.
- GNU General Public License v3.0 only, texte de la licence, dépôt officiel spdx/license-list-XML, https://github.com/spdx/license-list-XML/blob/main/src/GPL-3.0-only.xml, consulté le 07/10/2026.
- Business Source License 1.1, texte de la licence, dépôt officiel spdx/license-list-XML, https://github.com/spdx/license-list-XML/blob/main/src/BUSL-1.1.xml, consulté le 07/10/2026.
- Why the GNU Affero GPL, Free Software Foundation, https://www.gnu.org/licenses/why-affero-gpl.html, consulté le 07/10/2026.
- Frequently Asked Questions about the GNU Licenses, question « UnreleasedMods », Free Software Foundation, https://www.gnu.org/licenses/gpl-faq.html#UnreleasedMods, consulté le 07/10/2026.
- HashiCorp adopts Business Source License (10 août 2023), HashiCorp, https://www.hashicorp.com/en/blog/hashicorp-adopts-business-source-license, consulté le 07/10/2026.
- CycloneDX Bill of Materials Specification (ECMA-424), dépôt officiel CycloneDX/specification, https://github.com/CycloneDX/specification, consulté le 07/10/2026.
- ECMA-424, CycloneDX Bill of materials specification, Ecma International, https://www.ecma-international.org/publications-and-standards/standards/ecma-424/, consulté le 07/10/2026.
- License Scanning, documentation Trivy, dépôt officiel aquasecurity/trivy, https://github.com/aquasecurity/trivy/blob/main/docs/guide/scanner/license.md, consulté le 07/10/2026.
- Gitleaks, README, dépôt officiel gitleaks/gitleaks, https://github.com/gitleaks/gitleaks, consulté le 07/10/2026.
- Syft, README, dépôt officiel anchore/syft, https://github.com/anchore/syft, consulté le 07/10/2026.
- git-shortlog, documentation Git, dépôt officiel git/git, https://github.com/git/git/blob/master/Documentation/git-shortlog.adoc, consulté le 07/10/2026.