Maintenant que j’ai attiré votre attention grâce à ce titre qu’on pourrait qualifier de gentiment racoleur, laissez-moi vous expliquer plus concrètement le sujet de cet article.
Contexte et objectifs
Ces dernières semaines, en me replongeant dans la gouvernance informatique, j'ai réalisé qu'il était temps de partager la réalité du terrain concernant le SaaS B2B.
Que vous soyez en phase de conception ou déjà en commercialisation, vous l'avez peut-être remarqué : vendre à une grande entreprise n'a rien à voir avec le B2C. La marche est haute.
Si vous avez déjà prospecté une ETI ou une grande entreprise, vous avez peut-être subi le fameux 'Veto du DSI', parfois sans aucune explication, alors même que les équipes métier adoraient votre produit.
C'est frustrant, mais logique. Le DSI n'est pas là pour bloquer l'innovation, mais pour protéger sa forteresse. Sollicité en permanence, il n'a malheureusement pas le temps de faire de la pédagogie avec chaque éditeur pour expliquer pourquoi sa solution ne passe pas les barrières de sécurité.
L'objectif de cet article est de vous donner cette grille de lecture manquante (hors solutions On-Premise). Je vais lister les prérequis techniques indispensables pour que votre solution soit validée techniquement.
Respecter ces critères ne garantira pas votre succès commercial. Votre produit doit avant tout être bon. Mais cela vous évitera d'être disqualifié avant même d'avoir pu faire vos preuves.
Si ce guide permet à un seul d'entre vous de signer son premier grand compte, j'aurai accompli ma mission.
Qui suis-je?
Nicolas Mulot
CTO as a Service
Fort de 14 ans d'expérience en développement, dont 8 en tant que Lead Dev et CTO de solutions SaaS, j'ai piloté des projets de toutes tailles pour des clients variés. Habitué des audits de sécurité et des exigences de conformité, je décrypte pour vous ce que les DSI attendent réellement d'un logiciel pour transformer les contraintes techniques des grandes entreprises en opportunités business.
A qui s'adresse cet article ?
Cet article s'adresse à vous si vous créez un logiciel SaaS B2B, ou si vous commercialisez déjà une solution mais que vous vous êtes heurté à un rejet de la part de DSI de PME, d'ETI ou de Grandes Entreprises.
Selon votre profil, la lecture de cet article vous apportera des clés différentes :
Lead Devs, Lead Techs et CTOs
Pour comprendre les exigences techniques des grandes entreprises et maîtriser le vocabulaire qui parle concrètement aux DSI. Cet article vous aidera à construire une roadmap technique cohérente pour rendre votre solution "Enterprise Ready".
PMs, CPOs, CEOs et Décideurs
Pour anticiper les étapes techniques à franchir et les ressources à engager selon votre cible commerciale. Le sujet peut paraître complexe, mais accrochez-vous même si vous ne maîtrisez pas tout le jargon : c'est le fond qui compte. Voyez ce document comme un guide de survie du SaaS B2B, qui vous permettra d'économiser vos ressources en visant juste et au bon moment.
RSI et DSI
Pour confronter votre grille de lecture habituelle, auditer l'état actuel de votre parc applicatif ou simplement réviser certains standards du marché.
Introduction
Le Fossé Culturel entre l'Agilité Startup et la Rigueur Grand Compte
Dans le paysage technologique actuel, une dichotomie fondamentale persiste entre l'écosystème des startups, caractérisé par une agilité radicale et une itération rapide, et celui des grandes entreprises de plus de 5000 employés, régi par la stabilité, la gestion systémique du risque et la conformité réglementaire.
Un Directeur des Systèmes d'Information (DSI) d'une telle organisation, n'a pas pour responsabilité première l'adoption de l'innovation technologique. Ce qui lui importe avant tout c'est la préservation de l'intégrité du patrimoine informationnel de l'entreprise et la garantie de la continuité d'activité à grande échelle.
Lorsqu'une startup B2B présente une solution SaaS (Software as a Service) prometteuse, capable de révolutionner les processus métiers d'une entreprise, l'enthousiasme initial des directions fonctionnelles se heurte souvent au mur de la réalité technique et sécuritaire lors de la phase de "Due Diligence" informatique. Le DSI ne va pas uniquement regarder les fonctionnalités, l'interface utilisateur ou la promesse de valeur ajoutée immédiate. Il évalue la maturité structurelle, la résilience opérationnelle, la conformité juridique et la capacité de l'éditeur à s'insérer sans friction dans un Système d'Information (SI) complexe et interconnecté.
Le marché des logiciels d'entreprise a subi une mutation profonde au cours de la dernière décennie. L'époque où l'innovation se faisait en "mode pirate" (Shadow IT : utilisation d'outils informatiques sans approbation) est révolue pour les grands comptes soucieux de leur gouvernance. Aujourd'hui, les attentes en matière de conformité — telles que les certifications SOC 2 ou ISO 27001 — sont devenues des prérequis standards bien avant les séries de financement avancées, là où elles constituaient autrefois des différenciateurs de maturité tardive. Pour qu'un logiciel soit qualifié d'"Enterprise Ready", il doit traverser le gouffre qui sépare le produit viable minimum (MVP) de l'infrastructure critique auditée, capable de supporter la charge et les exigences d'une organisation multinationale.
Cet article a pour vocation de détailler, les exigences techniques, sécuritaires, juridiques et opérationnelles qu'un CTO (Chief Technical Officer) de startup doit impérativement intégrer dans sa feuille de route pour espérer signer un contrat cadre avec une grande entreprise. Il s'appuie sur les référentiels de marché, les standards exigeants du CIGREF (Club Informatique des Grandes Entreprises Françaises), les recommandations de l'ANSSI (Agence Nationale de la Sécurité des Systèmes d'Information) et les meilleures pratiques observées dans l'industrie. Ce document est conçu comme un outil de pilotage pour aligner votre trajectoire technologique aux impératifs de souveraineté et de sécurité des grandes entreprises.
En marketing, définir son 'Persona' est indispensable. Techniquement, la logique est la même : vous devez identifier la taille d'entreprise cible pour allouer vos ressources techniques au bon endroit, sans gaspillage.
Pour vous aider à visualiser la marche à gravir, je vais détailler les exigences spécifiques à chaque segment (TPE, PME, ETI et GE) à la fin de cette page. L'objectif de cet article est de vous faire entrer dans la tête d'un DSI : comprendre ses blocages est la meilleure façon de transformer votre audit de sécurité en simple formalité.
1. Gouvernance, Conformité et le "Cloud de Confiance"
Pour une grande entreprise européenne opérant dans un environnement réglementaire strict, la souveraineté des données et la conformité ne sont pas des cases à cocher, mais des piliers existentiels. Avant même d'examiner l'architecture technique ou la qualité du code, les DSI vont auditer la gouvernance de la donnée et la structure de confiance proposée par l'éditeur.
1.1. Conformité
Si la sécurité rassure le DSI, la conformité rassure le DPO (Data Protection Officer) et le Directeur Juridique. Sans ces validations, aucun contrat ne sera signé, même si votre technologie est révolutionnaire.
Voici les 4 acronymes qui régissent le marché B2B aujourd'hui :
RGPD (Le Socle Commun)
C'est le minimum syndical pour toute entreprise opérant en Europe ou traitant des données de citoyens européens.
Pour qui ?
Tout le monde (TPE, PME, ETI, GE).
L'impact pour vous :
DPA (Data Processing Agreement) :
Vous devez fournir une annexe contractuelle sur le traitement des données.
Droit à l'oubli :
Votre architecture doit permettre de supprimer totalement les données d'un utilisateur sur simple demande.
NIS2 (La Cybersécurité pour les secteurs critiques)
Entrée en vigueur récemment, cette directive européenne vise à sécuriser les entités critiques (Énergie, Transport, Banque, Santé, Eau, Infrastructures numériques, Gestion des services TIC B2B, etc.) de plus de 50 personnes ou de plus de 10 millions de CA. J'ai un peu simplifié les conditions, pour prendre les seuils minimums, mais vous pouvez retrouver les conditions exactes ici.
Pour qui ?
Si vous vendez à des "Entités Essentielles" ou "Importantes". En tant que fournisseur SaaS, vous faites partie de la "Supply Chain" (chaîne d'approvisionnement) de ces grands groupes. Ils ont désormais l'obligation légale d'auditer la sécurité de leurs fournisseurs.
L'impact pour vous :
On vous demandera une gestion des incidents rigoureuse (notification sous 24h/72h) et des mesures de sécurité prouvées (souvent alignées sur ISO 27001).
DORA (La Résilience pour la Finance)
Le Digital Operational Resilience Act est spécifique au secteur financier (Banques, Assurances, FinTech).
Pour qui ?
Si vous vendez à des institutions financières.
L'exigence DSI :
DORA ne demande pas seulement de la sécurité, mais de la Résilience.
Comment votre service redémarre-t-il après une catastrophe ?
Avez-vous un plan de sortie (Exit Strategy) ? Si votre startup fait faillite demain, comment la banque récupère-t-elle ses données pour les migrer ailleurs (Réversibilité) ?
HDS (Hébergement de Données de Santé)
C'est une certification française spécifique pour les données de santé.
Pour qui ?
Si votre solution SaaS touche, de près ou de loin (traitement ou sauvegarde), à des données de santé à caractère personnel (contexte RH, médecine du travail, assurance, bien-être des employés), la certification "Hébergeur de Données de Santé" (HDS) est une obligation légale stricte en France (Code de la Santé Publique), et non une simple "bonne pratique".
L'impact pour vous :
La certification HDS s'appuie sur le socle ISO 27001 et y ajoute des exigences spécifiques en matière de souveraineté, de droit des patients et de protection renforcée. Elle se décline en deux périmètres que le CTO doit maîtriser :
Hébergeur d'infrastructure physique :
Concerne les datacenters (ex: AWS, OVHcloud sont certifiés).
Hébergeur infogéreur :
Concerne l'éditeur SaaS qui administre la plateforme et gère les sauvegardes.
Une startup SaaS opérant sur AWS (certifié HDS infra) doit tout de même obtenir sa propre certification HDS (infogéreur) pour être en conformité. Ignorer cette nuance juridique expose le client et le fournisseur à des sanctions pénales lourdes.
1.2. Le Standard de Certification : ISO 27001 et SOC 2
Il est impératif pour tout CTO de comprendre que la certification n'est plus une option réservée aux acteurs établis. Les données de marché indiquent une accélération massive de la mise en conformité : 72 % des startups SaaS financées sécurisent désormais une conformité SOC 2 avant même leur levée de fonds en Série A, contre seulement 31 % en 2020 (selon Bigmoves Marketing). Cette tendance lourde reflète l'exigence croissante des grands donneurs d'ordre qui refusent d'intégrer des maillons faibles dans leur chaîne de valeur numérique.
ISO/IEC 27001 : Le Socle du Management de la Sécurité
L'ISO 27001 demeure le standard international de référence pour les grandes organisations européennes. Elle ne certifie pas uniquement la sécurité technique à un instant T, mais valide l'existence et l'efficacité d'un Système de Management de la Sécurité de l'Information (SMSI) vivant et dynamique.
Attente : Les DSI de Grande Entreprise peuvent exiger de consulter non seulement le certificat valide, mais également la Déclaration d'Applicabilité (SoA - Statement of Applicability). Ce document est crucial car il liste les mesures de sécurité que vous avez choisi d'implémenter ou d'exclure. Une exclusion injustifiée d'un contrôle critique (comme la gestion des clés cryptographiques) sera immédiatement signalée comme un risque majeur.
Preuve de maturité : La certification démontre que la sécurité est pilotée au niveau de la direction, qu'il existe une gestion des risques formalisée et que l'amélioration continue est intégrée dans les processus de l'entreprise.
SOC 2 Type II : La Preuve par l'Épreuve
Bien que d'origine nord-américaine (AICPA), le rapport SOC 2 (Service Organization Control) est devenu indispensable, souvent préféré à l'ISO 27001 pour sa granularité technique sur les services Cloud.
Type I vs Type II : Un rapport SOC 2 Type I atteste seulement que vos contrôles sont bien conçus à une date précise. Pour un grand compte, cela est insuffisant. Ils exigeront certainement un rapport SOC 2 Type II, qui audite l'efficacité opérationnelle de ces contrôles sur une période d'observation (généralement 6 à 12 mois). Cela prouve que vous ne vous contentez pas d'écrire des procédures, mais que vous les appliquez quotidiennement (par exemple, que les revues d'accès ont bien eu lieu chaque trimestre sans exception).
Critères de Confiance (Trust Service Criteria) : Au-delà de la Sécurité (critère commun obligatoire), les DSI de grande entreprise sont particulièrement attentifs aux critères de Disponibilité (pour les applications critiques) et de Confidentialité.
1.3. Souveraineté Numérique et Cloud de Confiance (Référentiel CIGREF)
Le contexte géopolitique (Cloud Act américain, lois chinoises sur le renseignement) et réglementaire a poussé les grandes entreprises françaises, via le CIGREF, à définir des critères stricts pour le "Cloud de Confiance". L'objectif est de se prémunir contre l'extraterritorialité du droit étranger qui pourrait permettre à une puissance étrangère d'accéder aux données industrielles sensibles de vos clients.
L'appel d'offres type du CIGREF intègre désormais un cahier des charges de plus de 250 critères techniques et juridiques pour évaluer ce niveau de confiance. En tant que fournisseur SaaS, vous devez vous positionner clairement sur cet échiquier :
Immunité Juridique :
Vos données (et celles de vos sous-traitants) sont-elles soumises au Cloud Act? Si vous hébergez les données sur un hyperscaler américain (AWS, Azure, GCP), même dans des datacenters situés à Paris ou Francfort, elles restent potentiellement accessibles aux autorités américaines via la maison mère.
Mesures Compensatoires :
Si vous utilisez ces plateformes (ce qui est le cas de la majorité des startups), les grandes entreprises exigeront des mesures techniques fortes pour garantir leur souveraineté, notamment le chiffrement dont ils détiendront les clés.
BYOK (Bring Your Own Key) : Pour les données les plus sensibles et pour garantir l'immunité contre le Cloud Act, la capacité de gérer leurs propres clés de chiffrement (via AWS KMS ou Azure Key Vault dédiés) est un différenciateur majeur. Cela garantit techniquement qu'en cas de réquisition judiciaire ou d'intrusion chez vous, les données restent illisibles sans leur clé, qu'ils peuvent révoquer à tout moment. C'est souvent l'argument ultime pour convaincre un RSSI réticent.
Transparence de la Chaîne de Valeur :
Vous devez cartographier l'intégralité de votre chaîne de sous-traitance. Si votre service passe par une API hébergée aux États-Unis ou si votre support technique est opéré depuis un pays hors adéquation RGPD, cela doit être déclaré. L'opacité sur ce point est un motif de disqualification immédiat.
💡 Astuce !
Si vous visez une réglementation NIS2, DORA ou HDS, ne réinventez pas la roue et profitez-en pour lancer aussi une démarche de certification ISO 27001. C'est un standard international qui couvre une grande partie des exigences de ces réglementations. Dire "Nous sommes certifiés ISO 27001" vous aidera à abréger les discussions de conformité.
2. Le Plan d'Assurance Sécurité (PAS) et l'Architecture de Défense
Le Plan d'Assurance Sécurité (PAS) est la pièce maîtresse de la relation technique entre une startup et un grand compte lors de la phase contractuelle et opérationnelle. Contrairement à une plaquette commerciale "Security Whitepaper", le PAS est un document contractuel vivant, opposable, qui décrit comment vous sécurisez spécifiquement le périmètre et les données du client.
2.1. Structure et Exigences Détaillées du PAS
Selon les directives de l'ANSSI et les pratiques des grands groupes industriels (type TotalEnergies ou secteurs bancaires), le PAS doit couvrir de manière exhaustive les domaines suivants, et le CTO doit être prêt à défendre chaque point devant les experts SSI du client.
Composantes Critiques du Plan d'Assurance Sécurité (PAS) :
Domaine du PAS | Exigences Techniques et Organisationnelles pour la Startup | Preuves Attendues |
|---|---|---|
Gouvernance SSI | Identification du RSSI (ou responsable sécurité) chez la startup. Politique de classification des données. | Organigramme SSI, PSSI (Politique de Sécurité du SI). |
Cloisonnement (Tenant Isolation) | Description technique de l'isolation des données client. Comment garantissez-vous qu'une faille sur le Client A ne permet pas d'accéder aux données du Client B? (Isolation logique via tenant_id dans toutes les requêtes SQL, chiffrement par clé unique par tenant). | Schémas d'architecture détaillés, revue de code des mécanismes d'isolation. |
Gestion des Vulnérabilités | Processus de veille (CERT, CVE, NVD). SLA (Service Level Agreement : contrat de niveau de service) de correction des failles (ex: Critique < 48h, Haute < 7j). Politique de patch management des OS et librairies tierces. | Rapports de scans automatisés, exemples de tickets de correction. |
Sécurité des Développements | Intégration de la sécurité dans le cycle de vie logiciel (SDLC : Software Development Lifecycle). Utilisation de SAST (Static Application Security Testing) et DAST(Dynamic Application Security Testing) dans la CI/CD. Formation des développeurs au Secure Coding (OWASP). | Captures d'écran des pipelines CI/CD montrant les étapes de sécurité bloquantes. |
Cryptographie | Standards utilisés (AES-256 pour le stockage, TLS 1.2 ou 1.3 pour le transit). Gestion du cycle de vie des clés (rotation, révocation). Usage de HSM (Hardware Security Modules) ou services KMS cloud (Key Management Service). | Politique de chiffrement, matrice des flux chiffrés. |
Sécurité RH et Accès | Qui a accès à la production? Vérification des antécédents des équipes (background checks). Procéssus JML (Joiner/Mover/Leaver). Principe du moindre privilège. | Politique de gestion des accès, liste anonymisée des profils administrateurs. |
Gestion des Incidents | Procédure de détection, qualification et notification. Engagement de notification de violation de données (< 24h ou 48h selon RGPD). | Logigramme de gestion de crise, modèles de communication de crise. |
2.2. Audits, Pentests et Transparence Continue
La confiance n'exclut pas le contrôle. Les entreprises n'acceptent plus de "croire sur parole" ou de se contenter d'un rapport vieux de deux ans.
Tests d'Intrusion (Pentests) Récurrents : Vous devez faire réaliser des tests d'intrusion complets (Grey Box) sur votre application et vos API au minimum une fois par an, et après chaque mise à jour majeure. Ces tests doivent être menés par des auditeurs tiers qualifiés (la qualification PASSI en France est un gage de qualité reconnu par l'ANSSI). Les entreprises exigent l'accès au résumé exécutif et à la lettre d'attestation de correction des failles critiques.
Droit d'Audit (Clause d'Audit) : Certain contrats avec de grandes entreprises incluront une clause leur permettant d'auditer (eux-mêmes ou via un tiers) votre conformité. Bien que rarement activée pour des petites startups si les rapports SOC 2 sont propres, le refus de cette clause est un signal d'alarme majeur quant à l'opacité de vos opérations.
Scan de Code et Dépendances (SCA) : Avec la montée des attaques sur la supply chain logicielle (type Log4j), les entreprises attendent que vous surveilliez vos dépendances open-source. L'intégration d'outils de SCA (Software Composition Analysis) comme Snyk ou Dependabot est surveillée pour garantir qu'ils n'hériteront pas de vulnérabilités connues via vos librairies.
2.3. Sécurité Applicative, Protection API et WAF
Votre infrastructure doit être robuste face aux menaces externes. Pour une grande entreprise, une indisponibilité causée par une attaque DDoS sur votre service a des répercussions financières immédiates.
Web Application Firewall (WAF), protection DDoS et CDN
L'utilisation d'un WAF couplé à une solution anti DDoS et un CDN (Cloudflare, AWS WAF, AWS Shield, Google Cloud Armor, Akamai, etc.) est nécéssaire. Votre WAF doit être configuré pour filtrer automatiquement les attaques courantes du OWASP Top 10. C'est une case indispensable à cocher dans les questionnaires de sécurité des grands comptes.
Rate Limiting
Vous devez implémenter un rate limiting intelligent à plusieurs niveaux (IP, User ID, Token). Dans une architecture multi-tenant, c'est la seule protection contre le problème du "Noisy Neighbor" ("Voisin Bruyant"), où un client légitime mais dysfonctionnel sature vos ressources au détriment des autres. Les stratégies de limitation doivent être granulaires (par endpoint, par méthode HTTP) pour ne pas impacter l'expérience utilisateur légitime.
Documentez clairement vos limites d'appels API (quotas, burst). Dans un contexte d'entreprise, ils doivent être assurés que leurs traitements batch de nuit ne seront pas bloqués aléatoirement par des limites opaques.
Sécurisation des API
Vos API, souvent le cœur de l'intégration Enterprise, doivent être protégées contre le credential stuffing et le scraping. L'authentification forte (OAuth2, mTLS pour le B2B) est non négociable.
3. Gestion des Identités et des Accès (IAM) : La Porte d'Entrée Unique
Pour une grande entreprise, la gestion manuelle des comptes utilisateurs (création par email, mot de passe partagé, suppression manuelle) est une hérésie opérationnelle et une faille de sécurité critique. L'intégration à leur système d'information passe obligatoirement par une fédération d'identités robuste.
3.1. Single Sign-On (SSO) : L'Exigence Absolue
Le SSO n'est pas une fonctionnalité "Enterprise" premium que l'on peut vendre en option coûteuse ("SSO Tax") sans friction ; c'est un prérequis d'hygiène de base pour tout déploiement large.
Protocoles Standards : L'entreprise doit pouvoir connecter votre application à leur IdP (Identity Provider) d'entreprise, qui est généralement Microsoft Azure AD (Entra ID), Okta, ou PingIdentity. Vous devez supporter nativement SAML 2.0 ou OIDC (OpenID Connect). Les solutions propriétaires ou les bricolages maison sont proscrits pour des raisons de maintenabilité et de sécurité.
Expérience Utilisateur et Sécurité : Le SSO élimine la fatigue des mots de passe pour les employés et permet d'appliquer leurs propres politiques de complexité et de rotation. Plus important encore, il centralise le point de contrôle : s'ils détectent une compromission, ils bloquent le compte sur leur IdP et l'accès à votre SaaS est coupé instantanément.
Authentification Multi-Facteurs (MFA) : Si, pour des raisons techniques (accès administrateur hors domaine, comptes techniques), le SSO ne peut pas être activé pour certains utilisateurs, votre application doit obligatoirement proposer et forcer le MFA (TOTP, WebAuthn/FIDO2). L'absence de MFA est un "No-Go" pour toute application hébergeant des données sensibles.
3.2. Provisioning et Cycle de Vie Automatisé (SCIM)
C'est souvent sur ce point précis que les startups échouent techniquement face aux exigences des grands comptes. Le SSO gère l'authentification (l'entrée), mais qui gère le cycle de vie du compte (l'arrivée, le changement de poste, le départ)?
Le Risque des "Comptes Fantômes" : Lorsqu'un employé quitte une entreprise, son accès doit être révoqué partout. Si votre application ne supporte que le SSO JIT (Just-in-Time) qui crée le compte à la volée, elle ne saura jamais que l'employé est parti. Le compte reste actif dans votre base, potentiellement accessible via des méthodes de secours ou des tokens API persistants. C'est un risque de fuite de données inacceptable (Zombie Accounts).
Le Standard SCIM 2.0 (System for Cross-domain Identity Management) : Vous devez supporter le protocole SCIM pour permettre aux annuaires d'entreprise de piloter ("Push") la création, la mise à jour des attributs (changement de nom, de service) et surtout la désactivation des comptes dans votre SaaS. L'automatisation de l'offboarding est un critère clé de validation pour les équipes de sécurité opérationnelle.
3.3. Modèle de Rôles (RBAC) et Ségrégation des Devoirs
La structure d'une grande entreprise est intrinsèquement hiérarchisée et segmentée. Le modèle binaire "Admin" vs "User" est insuffisant.
RBAC Granulaire (Role-Based Access Control) : Les entreprises ont besoin de rôles prédéfinis riches (ex : Lecteur Seul, Éditeur, Admin Technique, Admin Facturation, Auditeur) et idéalement de la possibilité de définir des rôles personnalisés (Custom Roles) basés sur des permissions atomiques.
Ségrégation des Devoirs (SoD) : Pour les applications critiques (Finance, ERP, RH), assurez-vous qu'un même utilisateur ne puisse pas cumuler des droits conflictuels (ex: initier un paiement et le valider).
Visibilité des accès : Ils ont besoin d'outils pour auditer "qui a accès à quoi" dans votre outil. Un rapport exportable des droits utilisateurs est nécessaire pour leurs revues d'habilitation périodiques.
Gestion des élévations de droits : Toutes élévations de droit critique (ex : on passe de Lecteur à Admin Technique) doivent déclencher directement une alerte au RSI, au DSI, ou aux personnes compétentes. Cela leur permet de détecter rapidement une élévation de droit non voulue et d'être proactif.
4. Données : Réversibilité, Journalisation et Auditabilité
La donnée appartient au client. Ce principe doit se traduire techniquement par une capacité totale de récupération et de traçabilité. Le "Vendor Lock-in" par la donnée est une crainte majeure des DSI.
4.1. La Clause de Réversibilité et l'Export de Données
La réversibilité est la capacité technique et contractuelle de récupérer l'intégralité des données de l'entreprise en fin de contrat pour les migrer vers un autre système ou les internaliser. C'est un point critique surveillé par le CIGREF et les juristes.
Formats Standards et Documentés : L'export ne doit pas être un "dump" SQL brut inexploitable ou un format propriétaire obscur. Un format de fichier standard ouvert sera exigé : JSON, CSV, XML pour les données structurées, et les formats natifs pour les fichiers (PDF, DOCX). Le schéma de données doit être documenté pour permettre la réingestion.
Exhaustivité du Périmètre : L'export doit inclure les données saisies, les données générées par le système (calculs, workflows), les métadonnées (qui a créé quoi, quand), les fichiers joints et les journaux d'audit. Tout ce qui constitue leur historique d'activité doit être restituable.
Autonomie (Self-Service) : Idéalement, la fonction d'export global doit être accessible en self-service via l'API ou la console d'administration pour les administrateurs, sans nécessiter l'ouverture d'un ticket support qui prendrait des semaines. Cela rassure sur votre transparence.
4.2. Destruction Sécurisée des Données
Attention à ne pas confondre le "Droit à l'oubli" (RGPD) qui concerne un utilisateur, avec la
Destruction de fin de contrat qui concerne toute l'entreprise cliente.
Lorsque le contrat s'arrête, le DSI exige une garantie absolue qu'aucune donnée confidentielle (stratégie, finances, secrets métiers) ne persiste dans votre infrastructure. Le défi technique ? Vos sauvegardes. Il est difficile d'aller supprimer les données d'un client spécifique dans un backup stocké sur une bande magnétique ou un AWS Glacier sans tout corrompre.
La solution attendue : Le Crypto-Shredding pour rassurer totalement un Grand Compte, l'idéal est d'avoir une architecture où chaque client (Tenant) possède sa propre clé de chiffrement.
Au moment du départ : Vous ne tentez pas d'écraser les disques (impossible dans le Cloud). Vous détruisez simplement la clé de chiffrement du client.
Le résultat : Toutes les données, y compris celles présentes dans vos sauvegardes historiques, deviennent instantanément et mathématiquement indéchiffrables.
La preuve : Vous fournissez un "Certificat de destruction de la clé", ce qui vaut juridiquement destruction des données.
4.3. Journalisation et Intégration SIEM (Security Information and Event Management)
En cas d'incident de sécurité ou d'enquête interne (fraude), les entreprises doivent savoir "qui a fait quoi, quand et depuis où".
Audit Logs Immuables : Chaque action structurante (login, lecture de donnée sensible, modification de configuration, export de masse, changement de droits) doit générer un événement de journalisation (log).
Contenu Standardisé des Logs : Chaque log doit contenir au minimum : Timestamp précis (NTP synchronisé), Identifiant Unique de l'Utilisateur (et non juste un nom), Adresse IP source, Type d'Action, Ressource visée, et Résultat de l'action (Succès/Échec/Refus).
Capacité d'Export SIEM : Les grandes entreprises ne veulent pas se connecter à votre dashboard propriétaire pour consulter les logs un par un. Vous devez permettre l'export automatisé des logs vers leur SIEM (Splunk, QRadar, Azure Sentinel). Les méthodes standards sont l'API REST de logs (pull) ou le dépôt automatique de fichiers logs plats dans un bucket S3 sécurisé qu'ils contrôlent (push). C'est une exigence vitale pour leur SOC (Security Operations Center) qui doit corréler vos événements avec le reste de leur SI.
4.4. Chiffrement au Repos et en Transit
Le standard minimal est TLS 1.2 ou 1.3 pour tous les flux réseaux (transit) et AES-256 pour le stockage (repos) des bases de données et des fichiers.
5. Excellence Opérationnelle : SLA, Support et Continuité
Une grande entreprise ne peut pas dépendre d'un logiciel qui "fait de son mieux". Ils achètent une garantie de service et une assurance de continuité. Les pannes ont un coût direct sur leur productivité.
5.1. SLA (Service Level Agreement) et Mécanismes de Pénalités
Un SLA sans pénalités financières n'est qu'une promesse marketing sans valeur contractuelle.
Disponibilité Garantie : Ils attendent généralement un engagement de disponibilité mensuelle de 99,9 % (soit ~43 minutes d'indisponibilité max par mois) pour les outils standards, et 99,99 % pour les outils critiques.
Calcul des Crédits de Service : Le contrat doit stipuler des crédits de service automatiques (avoirs sur la facture suivante) en cas de non-respect.
Exemple type : 10 % de pénalité si disponibilité < 99.9 %, 25 % si < 99.0 %, 50 % si < 98.0 %.31
Exclusions Claires : Les fenêtres de maintenance planifiées (annoncées à l'avance et effectuées hors heures ouvrées) sont généralement exclues du calcul, mais elles doivent être raisonnables.
Transparence (Status Page) : Une page de statut publique ou privée, mise à jour en temps réel et historisée, est obligatoire. Elle doit détailler l'état des différents composants (API, Front, Workers, Database).
Voici quelque exemple :
5.2. Résilience : RTO, RPO et Plan de Reprise d'Activité (PRA)
En cas de désastre majeur (incendie de Data Center type OVH Strasbourg, cyberattaque massive par rançongiciel chez vous), à quelle vitesse et dans quel état vont-ils pouvoir reprendre le travail?
RTO (Recovery Time Objective) : Temps maximal d'interruption admissible avant retour à la normale.
Standard SaaS : < 4 heures pour les applications critiques, < 24 heures pour le non-critique.
RPO (Recovery Point Objective) : Perte de données maximale admissible (ancienneté de la dernière sauvegarde restaurée).
Standard SaaS : La tolérance est rarement plus de 1 à 4 heures de perte de données pour les systèmes transactionnels. Pour les systèmes très critiques, il faut viser un RPO proche de zéro (réplication synchrone).
Tests de PRA : Avoir un plan sur papier ne suffit pas. Vous devez prouver que votre PRA est testé techniquement au moins une fois par an (bascule réelle ou simulation table-top) et fournir un compte-rendu succinct des résultats.
5.3. Support Technique et Niveaux de Service
Une grande entreprise est répartie potentiellement sur plusieurs fuseaux horaires, elle ne peut pas se contenter d'un support par email ou chat asynchrone basé sur un fuseau horaire unique (ex : Pacific Time ou Indian/Reunion).
Délais de Réponse (GTR/GTI)
GTI : Garantie de Temps d’Intervention
Le DSI de grande entreprise ne veut pas seulement un message automatique mais une vraie réponse humaine qui montre que la demande a bien été prise en compte.
GTR : Garantie de Temps de Rétablissement
C'est le temps maximum avant le retour à la normale. Ce temps se calcule à partir du signalement.
Les types de maintenances
Afin de spécifier correctement vos GTI et GTR, il faut bien faire la distinction entre les types de maintenance dans vos contrats afin d'éviter que cela finisse par vous coûter cher contractuellement.
La Maintenance Corrective (Les "Priorities" de P1 à P4)
C'est tout ce qui relève du "Ça ne marche pas comme prévu".
- La situation : Le logiciel est cassé, il y a une erreur, une lenteur anormale ou une faute de frappe.
- L'obligation : Vous avez une obligation de résultat (réparer) assortie de pénalités si vous dépassez les délais (SLA).
La Maintenance Évolutive (Les "Feature Requests")
C'est tout ce qui relève du "Je voudrais que ça fasse ça en plus".
- La situation : Le client "Aimerais un bouton ici", "Aimerais que l'export soit en PDF au lieu de CSV", "Aimerais pouvoir changer la couleur du header".
- L'obligation : Vous n'avez aucune obligation de délai contractuelle (sauf s'il y a un paiement et un contrat pour un développement spécifique). C'est soumis à votre roadmap produit.
Priorisation de la Maintenance Corrective
Les DSI de grande entreprise distinguent les incidents bloquants (P1 - Production arrêtée, tout le monde est bloqué) des demandes mineures.
P1 : Priorité Critique (L'urgence absolue)
La situation : "Tout est cassé". L'application est totalement inaccessible (Down), ou une fonctionnalité vitale (comme le paiement ou le login) ne fonctionne plus pour l'ensemble des utilisateurs. Il y a un risque de perte de données ou un impact financier direct et immédiat.
Attente du DSI : Branle-bas de combat. On s'attend à ce que vos équipes techniques soient sur le pont 24/7/365 jusqu'à la résolution.
SLA typique :
GTI : Réponse garantie en moins de 1 heure.
GTR : Résolution en moins de 4 heures.
P2 : Priorité Haute (Majeur mais pas bloquant total)
La situation : Le service est très dégradé (très lent), ou une fonctionnalité importante est cassée, mais il existe une solution de contournement (workaround) pénible, ou cela ne touche qu'une partie des utilisateurs. Le business continue, mais "ça grince fort".
Attente du DSI : Une prise en charge rapide et prioritaire par rapport au développement produit.
SLA typique :
GTI : Réponse garantie en moins de 2 heures
GTR : Résolution en moins de 24 heures (1 jour ouvré).
P3 : Priorité Moyenne (Le bug standard)
La situation : Un bug fonctionnel qui gêne l'utilisation mais n'empêche pas de travailler. Exemple : une fonction d'export qui échoue parfois, ou un bouton mal placé.
Attente du DSI : Que cela soit planifié dans le prochain sprint ou patch correctif.
SLA typique :
GTI : Réponse garantie en moins de 24 heures (1 jour ouvré)
GTR : Résolution en moins de 30 jours ouvrés.
P4 : Priorité Basse (Cosmétique)
La situation : Tout ce qui relève de la finition (Faute d'orthographe, problème d'alignement visuel, etc.)
Attente du DSI : Que cela soit pris en compte.
Attention : Si un ticket P4 est ouvert et que 6 mois plus tard, ce n'est toujours pas corrigé, le message envoyé est : "Nous négligeons les détails". Si vous négligez les détails visibles, ils vont commencer à avoir peur que vous négligiez la sécurité ou la qualité de code. Un P4 corrigé vite prouve l'excellence de votre équipe.
SLA typique :
GTI : Réponse garantie en moins de 2 jours ouvrés.
GTR : Pas d'engagement ferme, mais ne pas négliger ces demandes qui prouvent votre sérieux.
Langue et Localisation
Pour une entreprise française, la capacité à fournir un support en français (ou a minima un anglais technique impeccable) aux heures de bureau européennes est un atout considérable. L'externalisation vers des BPO spécialisés peut permettre d'atteindre ce niveau de service 24/7 sans exploser vos coûts.
6. Intégration, API et Écosystème Technique
Votre logiciel ne vivra pas en vase clos. Il doit s'insérer dans un Système d'Information hétérogène, composé de briques modernes et de systèmes "Legacy" (ERP, Mainframe). L'intégrabilité est un critère de choix décisif.
6.1. Stratégie "API First" et Documentation
L'intégration ne doit pas nécessiter des mois de développement sur mesure ou de "Professional Services" coûteux.
Couverture API : Il faut viser une couverture API à 100 %. Tout ce qui est faisable via l'interface utilisateur (créer un objet, lancer un traitement, extraire un rapport) doit être faisable via API REST ou GraphQL. Cela permet aux entreprises d'automatiser leurs processus via leurs outils d'orchestration (RPA, iPaaS).
Documentation Développeur : Une documentation API statique (PDF) est insuffisante. Ils attendent une documentation interactive standard (Swagger/OpenAPI) à jour, avec des exemples de code clairs.
Webhooks et Event-Driven : Pour l'automatisation, ils préfèrent les architectures événementielles. Votre système doit être capable d'envoyer des Webhooks lors d'événements métiers (ex : "Contrat signé", "Utilisateur créé") pour déclencher leurs workflows internes, évitant ainsi le polling constant de vos API qui surcharge les deux parties.
L'API et sa documentation ne doivent pas être une arrière-pensée : ce sont des fondations à poser dès le premier jour ("API First"). Pour garantir la pérennité d'un SaaS, il faut anticiper le scaling et l'évolutivité.
Concrètement, cela impose une architecture découplée (type 3-tiers) : votre Backend expose les données via une API documentée, qui est consommée par votre Frontend. Cette rigueur initiale vous permettra non seulement de maintenir une application web performante, mais aussi de déployer une application mobile ou d'ouvrir vos services à des partenaires sans avoir à tout recoder.
6.2. Gestion des Environnements et des Déploiements
Vous devez structurer votre architecture avec des environnements distincts répondant à des objectifs précis. La hantise absolue d'un DSI de grande entreprise est de vous voir effectuer des tests en production. Cela témoigne d'un manque de maturité dangereux (le fameux "Testing in Prod").
Voici un exemple de structuration acceptée et que vous pourrez décrire dans vos contrats (PAQ) :
L'Environnement de Production (PROD)
C'est le "Saint des Saints". C'est l'environnement réel, stable, performant et sécurisé où transitent les données critiques de l'entreprise.
Caractéristique clé : Il doit être inviolable par les développeurs (aucun accès direct à la base de données). C'est sur cet environnement que s'appliquent vos garanties SLA et où sont effectuées les sauvegardes quotidiennes.
Usage : Utilisation réelle et quotidienne par les clients finaux.
L'Environnement de Staging ou Pré-Production (PRE-PROD)
C'est le miroir de la production. Il sert à valider une version candidate (Release Candidate) avant qu'elle ne soit poussée en production.
Caractéristique clé :
Il doit être "Iso-Prod" (Iso-fonctionnel et Iso-architecture). Cela signifie qu'il possède la même configuration serveur, les mêmes versions logicielles et une volumétrie de données similaire à la production.
Usage :
C'est ici que l'on effectue les ultimes tests de non-régression et les UAT (User Acceptance Tests) avant le déploiement final.
⚠️ Attention au piège du RGPD !
Si vous souhaitez avoir une volumétrie de données réaliste sur votre PRE-PROD, ne copiez jamais la base de données de Production telle quelle. Un DSI vigilant vérifiera systématiquement si vous pratiquez l'anonymisation des données (Data Masking). S'il constate la présence de vrais noms, emails ou salaires de ses employés sur votre environnement de pré-prod (qui est souvent moins sécurisé ou accessible à plus de développeurs), c'est une non-conformité majeure qui peut rompre le contrat.
L'Environnement de Développement (DEV)
C'est l'environnement interne dédié à vos équipes techniques. Il permet d'effectuer des déploiements rapides pour tester du code sur une infrastructure serveur, sans impacter les environnements stables.
Caractéristique clé :
Il est très volatil. On peut y casser des fonctionnalités, redémarrer les services à volonté et déployer du code instable sans aucun risque et sans attendre que cela soit testé en PRE-PROD.
Usage :
Permet à vos développeurs de valider techniquement une fonctionnalité avant de la fusionner (merge) dans la branche principale. C'est un gain de temps pour les tests de vos équipes techniques, ce qui vous offre un gain de qualité pour votre produit.
L'Environnement Sandbox (BAC À SABLE)
C'est l'environnement dédié à vos clients. Il leur permet de tester votre solution avant signature, ou de valider des intégrations techniques sans polluer leurs données de production. C'est souvent l'environnement oublié par les startups, pourtant indispensable pour l'intégration.
Caractéristique clé :
Il est déconnecté de la réalité. On peut y créer des données fictives, générer de faux trafics et faire des erreurs sans conséquence.
Usage :
Permettre aux équipes de tester le fonctionnement de votre application, et à leurs développeurs de tester votre API en toute sécurité.
💡 Note Importante
Idéalement, votre architecture doit permettre d'instancier une Sandbox étanche par client. Un client A ne doit pas voir les données de test du client B, même s'il ne s'agit que de "fausses" données.
Zero Downtime Deployment
La phrase "On va couper le service 2h ce soir pour la mise à jour" est devenue inacceptable aujourd'hui pour un SaaS de qualité. Les clients attendent du Zero Downtime Deployment (ZDD). Les mises à jour de votre SaaS ne doivent pas interrompre le service. Les techniques de déploiement modernes (type Blue/Green) sont attendues pour garantir que la maintenance soit transparente pour vos utilisateurs.
7. La Feuille de Route de Maturité Technique
Face à la liste exhaustive des exigences que nous venons de voir, la tentation est grande de vouloir tout implémenter immédiatement. C'est une erreur classique qui peut asphyxier votre roadmap produit.
Dans un monde idéal, toutes ces cases seraient effectivement cochées dès le premier jour. Mais la réalité d'une startup est faite d'arbitrages permanents entre vélocité et conformité.
L'objectif de la matrice ci-dessous est de vous aider à prioriser. Elle met en lumière ce qui est strictement nécessaire pour débloquer une signature en fonction de votre interlocuteur (de la TPE au Grand Compte), mais aussi de vos moyens actuels. Elle vous permet également de situer votre maturité technique par rapport à ce à quoi vous pouvez vous attendre pour chaque type de levée de fonds (du Seed à la Série B+).
Gardez en tête que ce tableau est une boussole : s'il couvre la réalité d'une grande partie des éditeurs SaaS B2B, il devra être adapté à la marge selon votre contexte spécifique (notamment si vous visez des niches ultra-régulées). L'idée n'est pas d'être parfait partout, mais d'être "suffisamment robuste" là où votre client l'attend.
Légende
❗ Obligatoire (Réglementaire) Impératif légal ou contrainte stricte. Impossible de déroger à cette règle sous peine de sanctions ou d'illégalité immédiate.
✅ Nécessaire (Standard de marché) Fortement attendu pour convertir ce type de client. Si cette case n'est pas remplie, le risque de refus (No-Go) est très élevé et vos chances de signature diminuent drastiquement.
🚀 Atout (Nice to have) Un "plus" apprécié qui rassure le client et peut accélérer la vente. Cependant, l'absence de ce critère n'est généralement pas bloquante pour la signature.
⬜ Non Pertinent Critère rarement recherché ou évalué par ce type de client.
Conclusion : Ne cherchez pas à attraper la baleine avec une canne à pêche
Si vous êtes arrivés au bout de cet article, vous avez probablement le vertige face à la montagne de prérequis techniques. C'est normal. La marche entre un SaaS B2C et une solution adaptée aux Grandes Entreprises est immense. Il est important de garder les pieds sur terre.
Maintenant que vous avez une meilleure vision du sujet, voici 5 points essentiels que je souhaite mettre en avant :
1. Le No-Code a ses limites (le plafond de verre)
Les outils No-Code sont formidables pour itérer vite et valider un MVP. Mais soyons clairs : ils seront difficilement déployables chez une ETI ou un Grand Compte. Les contraintes d'auditabilité, de sécurité fine et de souveraineté des données qu'imposent ces grands acteurs sont souvent incompatibles avec les architectures fermées de ces plateformes.
2. Le ticket d'entrée est coûteux
Vendre à de grandes entreprises demande un investissement colossal. La mise à niveau technique représente un coût de développement significatif. C'est une barrière à l'entrée qu'il ne faut pas sous-estimer. Mais investir tôt dans ces fondations "invisibles" vous sera bénéfique sur le long terme.
3. Faites de votre équipe Tech un allié business
Pour vendre à des Grands Comptes, la relation relationnelle ne suffit plus : il faut convaincre des experts techniques exigeants. C'est là que votre CTO et vos Lead Techs deviennent des atouts majeurs pour épauler vos commerciaux. Ne les cantonnez pas au code : impliquez-les dans les phases finales de vente. Ce sont eux qui sauront trouver les mots pour rassurer un DSI et valider la faisabilité des promesses contractuelles. Une synergie forte entre vos équipes Vente et Tech est souvent le facteur clé pour débloquer ces signatures complexes.
4. Le piège de l'IA : Levier ou Remplacement ?
À l'heure où l'IA envahit le marché, beaucoup de fondateurs pensent pouvoir réduire leur équipe technique pour faire des économies. C'est une erreur stratégique majeure. Comme vous l'avez vu dans cet article, les exigences (Compliance, Sécurité, Ops) ont explosé ces dernières années. Vos équipes doivent maîtriser de plus en plus de sujets. L'IA n'est pas là pour remplacer vos équipes techniques, mais pour leur servir de point d'appui afin de porter cette charge grandissante. Si vous réduisez la voilure maintenant, sachez que vos concurrents, eux, maintiendront leurs équipes et utiliseront l'IA pour avancer deux fois plus vite et mieux. Ne leur donnez pas l'opportunité de vous écraser.
5. La stratégie avant la conformité
Enfin, ne voyez pas cet article comme une "To-Do List" immédiate. Ce serait du suicide entrepreneurial pour une startup qui débute. Le secret est d'aligner votre maturité technique avec votre cible commerciale. Concentrez vos efforts sur votre Product Market Fit avec des clients à votre portée, encaissez vos premiers revenus, et utilisez cette traction pour financer, brique par brique, votre montée en gamme technique.
La conformité n'est pas une fin en soi, c'est un levier de croissance qui doit s'activer au bon moment.
Bonne pêche ! 🎣
Parlons de votre projet
Vous souhaitez en savoir plus ou discuter de votre projet ?
Contactez-nous via notre formulaire de contact.
Nous serons ravis d’échanger avec vous sur vos objectifs et vous proposer des solutions adaptées.