Blog /

Dans l'épisode 1, on vous expliquait pourquoi on s'était lancés dans cette démarche ISO 27001/HDS. On voulait formaliser ce qu'on faisait déjà, se tester, se rassurer. Et puis on sentait que c'était le bon moment, avec notre bagage et notre appétence naturelle pour la cyber et les trucs bien faits.

Après, c'est bien beau de penser être prêts, mais dans les faits, on en est où ? (spoiler : à ce moment-là, on n'en a pas la moindre idée.)

Autant vous dire qu'entre « on pense bien faire » et « on fait vraiment bien » on va vite comprendre qu'il y a un monde et que « on a mis en place des trucs » en face d'un « c'est documenté, reproductible et auditable » ben ça ne pèse pas pareil dans le game.

En août 2025, on s'est donc posés avec Akant pour deux demi-journées d'ateliers. Deux sessions de questions-réponses intensives, méthodiques, parfois souvent douloureuses. Pour dresser un état des lieux complet de notre maturité par rapport au référentiel que l'on vise.

Spoiler encore : on n'est ni des bras cassés, ni des champions (bon, toute fausse modestie gardée, on est quand même pas mal 😇). On est une équipe tech qui fait de son mieux, avec des points forts sur lesquels capitaliser et des chantiers à mener.

Ah oui, et surtout on était bien naïfs ah ah ! Mais on en reparlera.

Analyse de maturité vs gap analysis

Première clarification importante : Akant nous a proposé une analyse de maturité plutôt qu'une simple gap analysis (ouais parce qu'en nous voyant débarquer la bouche en cœur, on n'a pas donné le change longtemps et ils ont sans doute vite compris qu'on était nouveaux dans le monde de la conformité).

La nuance (enfin c'est ce que nous, on a compris hein) ?

• Un gap analysis, c'est : « voilà ce que dit la norme, voilà ce que vous faites, voici la liste des trucs qui manquent ».
• Une analyse de maturité, c'est : « on regarde non seulement ce qui manque, mais aussi à quel point ce que vous faites est mature, documenté et reproductible ».

L'intérêt ? Ça permet de prioriser. Parce qu'entre un truc que tu ne fais pas du tout et un truc que tu fais avec la bonne vieille méthode R.A.C.H.E. bien connue dans la tech', sans documentation ni processus, l'effort n'est pas le même.

Et surtout, ça permet d'identifier les points forts sur lesquels capitaliser. Parce que oui, on fait déjà pas mal de choses bien, hein ! Je vous vois déjà faire les gros yeux « Roooh les nuls ! »

On ne fait pas toujours de la bonne manière et on ne formalise pas systématiquement, mais on ne part pas de zéro non plus.

Deux demi-journées de questions

Donc fin août 2025, comme nos clients étaient en train de se faire dorer la pilule, on s'est lancés dans deux sessions de 2 h où on s'est fait cuisiner façon « Bureau des légendes ».

Le format ? Une longue discussion structurée qui balaie tous les aspects de la sécurité de l'information :

• ressources humaines (contrats, onboarding, sensibilisation) ;
• gestion des identités et des accès ;
• postes de travail et gestion de la flotte ;
• gestion des incidents ;
• développement sécurisé ;
• protection des données personnelles ;
• infrastructure et réseau ;
• sauvegardes et continuité d'activité ;
• gestion des fournisseurs ;
• et j'en passe…

Et dès les premières questions, on se rend vite compte qu'en fait on n'avait aucune idée de ce qui nous attendait… Pour nous, on visait une certif orientée sécu opérationnelle, et ben… c'est un tout petit morceau en fait !

Et même si on a droit à un « Pour une boîte de votre taille, c'est quand même pas mal du tout », il faut avouer que régulièrement les échanges, c'était plutôt :

Ce qu'on faisait déjà bien

Commençons par les bonnes nouvelles. On n'est pas des pieds !

Gestion de la flotte

Toutes nos machines sont enrôlées dans un MDM, avec :

• chiffrement du disque forcé ;
• politique de mot de passe de session balaise ;
• firewall système forcé ;
• inventaire des applications installées ;
• on peut verrouiller/effacer les postes à distance.

Bref, on a tout de même de la visibilité et un minimum de contrôle sur notre flotte.

Gestion des secrets

On utilise un gestionnaire de secrets applicatif pour stocker : tokens JWT, credentials de bases de données, clés API… Tout ce qui est sensible passe par là.

À tous ceux qui lèvent les yeux en se disant « Bah évidemment ! » Vous savez aussi bien que nous ce qu'on voit passer parfois 😉.

Les mots de passe des collaborateurs, eux, sont dans un gestionnaire de mots de passe, et c'est obligatoire ! On s'engage en échange à former un minimum nos équipes (ça aussi, on en reparlera tiens !).

IAM et SSO

On a historiquement du Keycloak pour gérer l'authentification. On y reviendra, mais on a dû changer depuis. L'objectif à ce moment, c'est d'y faire passer tous les accès (on l'apprendra plus tard, mais chaque accès doit être tracé, donc soit t'as tout à un endroit avec ton SSO, tes audit logs… soit faut faire du cas par cas ! Et personne n'a envie de faire du cas par cas !).

MFA généralisé

On force déjà le MFA partout où c'est possible et bien sûr pas avec du SMS. Ça grince des dents de temps en temps (« encore un code à taper »), mais c'est non négociable.

Culture du post-mortem

Quand un incident a un impact significatif pour nos clients, on fait un post-mortem. Pas systématiquement sur tous les petits incidents (ça n'aurait pas vraiment de sens), mais dès qu'il y a interruption de service notable ou problème de sécurité, on documente :

• le déroulé ;
• la root cause analysis ;
• ce qu'on a appris ;
• les actions correctives.

Et ça, on apprendra vite que c'est un réflexe qui va nous servir notamment pour la traçabilité et les mises en œuvre des mesures correctives.

security.txt

On a déjà en place des fichiers security.txt sur nos sites (standard RFC 9116), qui indiquent :

• l'adresse pour signaler une vulnérabilité ;
• une clé GPG publique pour chiffrer les échanges ;
• un lien vers notre politique de divulgation responsable.

Ça commence à faire son trou dans l'écosystème cyber, et c'est le minimum syndical pour qu'un chercheur en sécurité sache comment nous contacter s'il trouve une faille.

Bon en vrai pour la certif, on s'en fout 🤷‍♂️…

Ah oui ! On aura l'occasion d'en discuter, mais la patience est la première des vertus parce que ça n'est pas rare qu'on se voie comme ça à l'issue d'un atelier :

Veille sécurité

On suit de près les CVE qui concernent nos stacks de prédilection (Symfony, PostgreSQL, Kubernetes…) via :

• des canaux RSS (oui, on n'est pas tout jeunes) ;
• Bluesky et Twitter X ;
• le CERT-FR ;
• des bases de CVE.

Dès qu'une faille tombe sur une techno qu'on utilise, on alerte les équipes et on pousse la mise à jour. Mais encore une fois, ça n'est pas industrialisé et traçable !

Ce qu'on pensait bien faire

Et là, ça devient intéressant. Parce qu'il y a un écart entre ce qu'on pense faire et ce qu'on fait vraiment.

« On a des sauvegardes »

Oui bon ben quand même ! On est peut-être un peu naïfs, mais on n'est pas demeurés non plus. Mais est-ce qu'on les teste ?

Sporadiquement. Quand on fait une migration. Ou quand un client nous le demande. Mais pas de manière systématique et documentée. Et comme on se le répète souvent : « Si tu ne testes pas tes sauvegardes, alors tu n'as pas de sauvegardes ». C'est la sauvegarde de Schrödinger : tant qu'on ne restaure pas, elle est à la fois fonctionnelle et corrompue.

Ah tiens… ?! Ça rigole moins d'un coup, sans doute que quelques-uns sont en train de se dire « Merde, c'est quand la dernière fois que j'ai vérifié que mes sauvegardes étaient intègres ? »

« Les équipes sont sensibilisées »

Oui, on fait des rappels. Oui, on a déjà eu des discussions sur le phishing, les mots de passe, les accès VPN…

Mais formalisé ? Avec un programme de sensibilisation structuré, des sessions régulières, du tracking des personnes formées ? Non.

On fait un brief sécu à l'arrivée d'un nouveau collaborateur, et après… on rappelle des trucs de temps en temps. C'est artisanal et bien loin d'être suffisant, d'autant plus que l'arrivée de l'IA rend les arnaques de plus en plus difficiles à déceler.

« On gère bien les accès »

On a un processus d'onboarding/offboarding. On a une issue en mode checklist avec tous les comptes à créer et à supprimer.

Mais les revues d'accès ? Non formalisées. « Quand on y pense », généralement quand quelqu'un arrive ou part. Mais pas de revue trimestrielle systématique pour vérifier qui a accès à quoi.

Et c'est un problème, parce que les accès, ça s'accumule. Quelqu'un qui change de rôle, un prestataire qui termine sa mission, un collaborateur qui quitte la boîte… Si tu ne nettoies pas régulièrement, tu te retrouves avec des comptes orphelins partout.

Les chantiers identifiés

Et maintenant, les gros morceaux. Ce qu'il faut vraiment améliorer.

Sensibilisation formalisée

On a découvert Riot lors de l'atelier avec Akant. Déjà, ils sont français, premier bon point, mais en plus, ils proposent une plateforme de sensibilisation à la cybersécurité, gratuite jusqu'à 10 personnes.

Le principe : un agent (Albert) qui vient pousser du contenu de sensibilisation de manière régulière via la messagerie d'entreprise, avec des modules courts. Il est aussi farceur Albert et il organise des simulations de phishing régulières, ainsi qu'un suivi des complétions.

Ça ne vaut pas de vraies formations tout au long de l'année, mais franchement ça fait déjà bien le boulot et c'est vachement bien foutu.

Formalisation des politiques

On a des chartes (informatique, télétravail), rédigées par notre RH suite à un audit l'an dernier. Mais elles ne couvrent pas tout ce qu'ISO 27001 demande.

Il va falloir compléter avec :

• une politique de gestion des accès ;
• une politique de classification des données ;
• une politique de gestion des incidents ;
• une politique de développement sécurisé ;
• une politique cryptographique ;
• et probablement d'autres… (lol, oh oui !)

Le risque : la sur-documentation. Des politiques que personne ne lit, que personne ne suit, et qui ne servent qu'à cocher des cases pour l'auditeur.

Notre objectif : rester pragmatiques. Des docs courts, actionnables, qui reflètent ce qu'on fait vraiment.

Et là on commence à se rendre compte que comme bien souvent le build est une chose mais que le run de tout ça sera essentiel et à ne pas négliger en termes de charge de travail.

PCA/PRA

On a un PRA (Plan de Reprise d'Activité) côté clients, parce que c'est notre métier. Mais côté interne ?

Qu'est-ce qui se passe si on n'a plus accès à notre messagerie ? À nos dépôts de sources ? À notre gestion documentaire ? Si on ne peut plus payer les salaires parce que notre prestataire est down ? (Bon, apparemment, ce dernier semble moins critique pour la direction…)

Il va falloir identifier nos processus critiques, définir des RTO/RPO (Recovery Time Objective / Recovery Point Objective), et documenter des solutions de repli.

Exemple con, mais réel : si la paie est indisponible en fin de mois, on fait quoi ? On appelle l'expert-comptable, on verse des acomptes « au doigt mouillé », et on régularise après. Mais ce n'est pas écrit. Et ça devrait.

EDR et protection des postes

Historiquement, on n'a pas d'antivirus.

Ma vision à ce moment (contestable, je sais) : un antivirus, ça ne détecte que ce qui est connu. Un zero-day, ça passe. Et je préfère miser sur la sensibilisation et le durcissement des postes que sur un outil qui donne un faux sentiment de sécurité.

Je vous ai dit qu'on était vieux ? Bah ouais, parce qu'on ne parle plus d'antivirus maintenant, mais d'EPP, d'EDR, d'XDR et de MDR (il a l'air marrant celui-là, mais il ne fera pas rigoler ton portefeuille !).

Bref, c'est vachement moins inutile que le bon vieux Norton de mamie qui met en PLS le PC au moindre scan.

De toute façon, dans un cadre ISO, on n'y coupera pas. Donc on va regarder des solutions légères et non intrusives, type EDR de nouvelle génération, qui font de l'analyse comportementale sans bouffer toutes les ressources. Mais on en reparlera.

DLP

On n'a aucun mécanisme de DLP (Data Loss Prevention). Si quelqu'un crée un partage public sur Infomaniak ou Google Drive, on n'est pas notifié.

Il existe des solutions, mais elles sont souvent lourdes, chères, et génèrent beaucoup de faux positifs.

Notre stratégie pour l'instant : sensibilisation et revues régulières des partages. Mais c'est un point qu'on garde sous le coude pour la suite.

Les premières décisions

À l'issue de ces ateliers, on a commencé à prioriser.

Quick wins

• déployer Riot sur les trois structures (facile et impact immédiat) ;
• formaliser les revues d'accès (trimestrielles, avec checklist) ;
• tester les sauvegardes (une fois par trimestre minimum, documenté) ;
• compléter les chartes existantes (en vrai, elles vont être complètement réécrites).

Chantiers moyen terme

• politiques de sécurité (rédaction, validation, déploiement) ;
• PCA/PRA interne (identification des processus critiques, scénarios de repli).

Chantiers long terme

• homogénéisation des outils entre les trois structures ;
• généralisation d'un SSO unique ;
• recherche d'une solution d'EDR.

Ce qu'on en retient

Il y a un écart entre « on fait » et « on fait bien »

On pensait être plutôt bons. Et on l'est, sur beaucoup d'aspects. Mais sans formalisation, sans documentation, sans processus reproductible, ce n'est pas suffisant.

L'exemple des sauvegardes est parlant : on en fait, on sait les restaurer, mais est-on certain de leur intégrité ? Si le dernier arrivé de l'équipe se retrouve à restaurer et que les autres ne sont pas disponibles, a-t-il le minimum nécessaire pour être autonome ? Est-ce que c'est écrit quelque part ?

La taille de la structure n'est pas un frein (si on s'y prend bien)

On est petits (une vingtaine au total, Rix et Elao). On pensait que ce serait un handicap, mais en fait, c'est plutôt un avantage (il faut bien en trouver, hein !).

On est agiles. On peut prendre des décisions rapidement. On peut déployer des outils en quelques jours. On a peu de couches hiérarchiques, peu de friction.

Les grosses boîtes rament pendant des mois à faire adopter une politique. Nous, on peut le faire en une semaine.

On ne partait pas de zéro

Et ça, c'est rassurant. On a une culture de la rigueur qui existe déjà. On n'a pas à convaincre les équipes que la sécurité, c'est important. Elles le savent et elles le vivent au quotidien avec les clients.

Bref ! Il « suffit » (Ah ah ah ! La blague !) de formaliser, structurer, documenter.

 Et surtout ! Le leitmotiv de la conformité

• Say what you do : Si ça n'est pas écrit, ça n'existe pas.
• Do what you say : Si ça n'est pas appliqué, c'est inutile.
• Prove it : Si ça n'est pas démontré, ça n'est pas fait.

Et enfin, il ne faut pas s'attendre à voir la ligne d'arrivée : le principe d'ISO 27001, c'est l'amélioration continue, et par définition, c'est sans fin.

Bref, on n'avait effectivement aucune idée de ce dans quoi on allait s'embarquer…

La suite

On a maintenant une feuille de route d'autoroute, qui ressemble plutôt à ce qu'on appelle une lettre au père Noël. Mais au moins, on sait où on en est, on sait où on doit aller, et on a une idée de l'effort à fournir (ndlr : Absolument pas !).

Prochaine étape : construire le SMSI (Système de Management de la Sécurité de l'Information), eh ouais, c'est le nouvel acronyme qu'on aura appris pendant cette journée, preuve qu'elle n'a pas été perdue.

Ça passe par :

• la rédaction des politiques ;
• l'analyse de risques complète ;
• la définition des mesures de sécurité ;
• la mise en place des indicateurs de suivi.

Et surtout, continuer à avancer tout en assurant le quotidien. Parce qu'on a toujours des clients à gérer, des infrastructures à maintenir, des projets à livrer.

On vous raconte bientôt la suite.

À suivre.

Les outils évoqués dans cet article

• Riot 🇫🇷 — Sensibilisation cybersécurité (gratuit jusqu'à 10 personnes)