On a fini notre audit ISO 27001 en janvier. Champagne, félicitations en interne, ligne ajoutée sur le site "sécurité et conformité". Six semaines plus tard, un client nous a signalé un comportement suspect sur une intégration tierce qu'on utilisait pour un projet annexe — hors du périmètre exact qu'on avait fait auditer. Rien de catastrophique, on a coupé l'accès en quelques heures. Mais la question nous est restée : qu'est-ce qu'on avait vraiment prouvé en janvier ?
On avait payé cher, mobilisé trois personnes pendant deux mois, produit des dizaines de documents. Et pourtant, l'incident est venu d'un endroit que personne n'avait pensé à inclure dans le périmètre certifié.
Ce n'est pas un cas isolé. Des entreprises comme Instructure (Canvas) ont renouvelé leur ISO 27001, leur SOC 2 Type II et leur conformité PCI DSS 4.0.1 fin 2025 — puis se sont fait attaquer deux fois en mai 2026, sur une fonctionnalité qui se trouvait hors du périmètre certifié. SolarWinds, MOVEit, Okta, Snowflake, Microsoft : toutes attestées SOC 2 au moment de compromissions majeures.
La question qu'on se pose depuis, chez ExpertItLab : est-ce qu'on vend de la sécurité à nos clients, ou est-ce qu'on vend une photo prise à un instant T ? Et si c'est une photo, pourquoi on continue à en parler comme d'une garantie ?
Ce que la certification prouve vraiment
Une certification, qu'elle soit ISO 27001, SOC 2 ou une conformité RGPD, prouve qu'un périmètre défini a été audité à un moment donné. Ce n'est pas rien — ça oblige à documenter les processus, à formaliser des politiques qu'on aurait sinon laissées dans la tête de deux ou trois personnes. Mais ça ne garantit ni la couverture de tous les systèmes, ni la résistance à une attaque réelle, ni la capacité à réagir sous pression un dimanche soir.
Un sondage Splunk cité en 2026 indique que 20% des RSSI interrogés ont subi une pression pour ne pas signaler un incident ou un problème de conformité, et 78% se disent préoccupés par leur propre responsabilité personnelle. Un autre sondage, Checkmarx, va plus loin : 95% des RSSI ressentent une pression pour retarder ou minimiser des sujets de sécurité liés à la conformité. Ce n'est pas un problème de mauvaise volonté. C'est un problème d'incitations : la certification devient un argument commercial, et l'argument commercial prend le pas sur le signal d'alerte.
Le coût réel, et pourquoi il est difficile à comparer
On a voulu chiffrer, en interne, si notre budget conformité était "rentable" face au risque d'incident. Ça s'est avéré plus compliqué que prévu. Les données disponibles sur le coût de la conformité sont nettement moins standardisées que celles sur le coût des incidents. Un rapport de la Banque Mondiale souligne cette difficulté structurelle : les estimations globales de coût des cyberincidents varient de 172 milliards à plusieurs trillions de dollars par an selon la méthode utilisée. Il n'existe pas de chiffre stable.
Ce qu'on sait quand même : NetDiligence évalue le coût moyen d'un incident à 246 000 dollars pour une PME et à 10,3 millions pour une grande entreprise. Et quand l'incident entraîne une interruption d'activité, le coût moyen grimpe de plus de 650%. Pour nous, PME de service, ce chiffre parle davantage que n'importe quel badge de certification : ce n'est pas la fuite de données qui nous mettrait le plus en danger, c'est l'arrêt de la livraison pour nos clients pendant plusieurs jours.
La tension qu'on vit avec nos propres clients
Beaucoup de nos clients, notamment dans le secteur financier ou assurantiel, nous demandent une certification avant même de discuter du projet. C'est devenu une case à cocher dans leurs appels d'offres. On comprend pourquoi : ça simplifie leur propre gestion du risque fournisseur. Mais on voit aussi, en interne, l'écart entre ce qu'on montre sur le papier et ce qu'on sait de nos vraies vulnérabilités — les dépendances tierces qu'on ne maîtrise pas totalement, les comptes de service qu'on n'a pas encore tous audités, les configurations qu'on ajuste au fil de l'eau.
On ne ment pas à nos clients. Mais on sait qu'on leur vend une garantie plus solide qu'elle ne l'est réellement, parce que c'est ce que le marché demande. Le badge rassure. La réalité opérationnelle est plus grise.
Ce qu'on a changé depuis
Après l'incident de janvier, on a arrêté de traiter la certification comme une ligne d'arrivée. On la traite maintenant comme un point de départ documentaire, et on a ajouté un exercice trimestriel qu'on appelle en interne "hors périmètre" : on liste explicitement tout ce qui n'est pas couvert par l'audit — les intégrations tierces, les outils annexes, les accès qu'on donne à des prestataires — et on regarde ce qu'on peut réellement dire si un de ces systèmes est compromis demain.
Ce n'est pas parfait. On découvre régulièrement des angles morts qu'on n'avait pas anticipés. Mais au moins, on ne prétend plus, en interne, que le certificat suffit à répondre à la question "est-ce qu'on est en sécurité".
Ce que les gros incidents nous ont appris sur nos propres angles morts
On a étudié le cas de GEICO — pas une entreprise tech, mais un exemple qui nous a marqués. Pendant une décennie, elle a migré des centaines d'applications vers un cloud majeur en pensant renforcer sa posture de sécurité et sa conformité. Ce n'est pas un incident de sécurité qui nous intéresse ici, mais le principe : la complexité accumulée sur dix ans de migration crée des zones que même une organisation mature ne maîtrise plus complètement. Chez nous, à une échelle bien plus modeste, on retrouve le même phénomène : chaque nouvel outil SaaS qu'on connecte, chaque nouvelle intégration API qu'on ajoute pour un client, élargit une surface qu'aucun audit annuel ne peut suivre en temps réel.
C'est là qu'on a compris que la vraie question n'était pas "sommes-nous conformes" mais "combien de temps s'écoule entre le moment où une nouvelle faille apparaît dans notre système et le moment où on la détecte". Cette métrique-là ne figure sur aucun certificat. Elle ne figure même pas encore clairement dans nos propres tableaux de bord internes, et c'est précisément ce qu'on est en train de corriger.
On n'a pas arrêté de faire certifier ExpertItLab. On continuera, parce que nos clients en ont besoin et que la démarche nous force à documenter des choses qu'on négligeait. Mais on a changé la phrase qu'on utilise en interne. On ne dit plus "on est certifiés donc on est protégés". On dit "on est certifiés sur ce qu'on a audité, et on ne sait pas encore tout ce qu'on n'a pas audité".
C'est moins confortable à écrire dans une plaquette commerciale. C'est plus honnête.
La question qu'on se pose maintenant, et qu'on n'a pas résolue : comment vend-on une sécurité réelle à des clients qui, structurellement, ne savent acheter que des certificats ? Est-ce qu'on continue à jouer le jeu du badge, en sachant ce qu'il ne couvre pas — ou est-ce qu'on prend le risque de dire à un prospect que sa checklist de conformité ne lui dit presque rien sur ce qui va vraiment lui arriver ?
Si vous portez la sécurité dans votre organisation : est-ce que votre dernier audit couvrait vraiment tout ce qui compte, ou juste ce qu'il était pratique de faire auditer ?
