La case AO : le syndrome du cadenas en PowerPoint.
Il y a un moment, dans un projet, où quelqu'un dit : "Il faut qu'on pense à la sécurité avant la livraison." Ce moment arrive toujours trop tard. Les choix d'architecture sont faits. La base de données est en place. Les identifiants de connexion à l'API tierce sont déjà écrits dans un fichier de configuration commité sur le dépôt. Le réseau n'a pas été segmenté parce que "on verra ça après". Et là, à trois semaines du go-live, quelqu'un ouvre la section "Cybersécurité" de la réponse à l'appel d'offres pour s'assurer que les cases sont cochées.
Le HTTPS est activé. Il y a une politique de mot de passe. Le prestataire "s'occupe de tout". La case est cochée.
Ce n'est pas de la cybersécurité. C'est de la cosmétique. Et la différence entre les deux, on la vit le jour où quelque chose se passe — pas avant.
Ce que la case AO mesure réellement
La section cybersécurité d'un AO mesure en général la capacité du prestataire à cocher des cases, pas à avoir pensé la sécurité comme une contrainte d'architecture. Ce n'est pas la même chose. La première compétence s'acquiert en une heure. La seconde prend des années de terrain et de ratés.
Pourquoi ça ne marche pas. Ce qu'on voit après.
En vingt-cinq ans de terrain — STERIS, MILCoMED, l'Industry Lab d'Orléans, SIGRENEA sur l'IoT industriel — j'ai vu suffisamment de projets livrés pour savoir ce qui se passe quand la cyber arrive en fin de chantier. Ce n'est pas spectaculaire. Ce n'est pas Hollywood. C'est prosaïque, coûteux, et largement évitable.
Anecdote plausible à valider
Un projet web pour une PME industrielle. L'application est en production depuis trois mois. Un auditeur externe, mandaté pour une certification, fait un test de pénétration basique. Il trouve en vingt minutes une injection SQL sur un formulaire de recherche que personne n'avait testé parce que "ce n'est pas un champ de saisie critique". La donnée exposée : des fiches clients avec des coordonnées et des historiques de commandes. Le correctif technique prend deux jours. L'audit de conformité, la notification CNIL, les échanges avec les clients concernés — trois semaines. Le coût total : difficile à chiffrer, mais significativement plus élevé que ce qu'aurait coûté un test d'intrusion en pré-production.
Anecdote plausible à valider
Un serveur NAS configuré en début de projet pour les sauvegardes. Personne ne s'en souvient vraiment — c'est l'ancien prestataire qui l'avait mis en place. Le partage réseau est visible depuis les postes de travail. Un ransomware entre par un poste mal patché, chiffre tout ce qu'il peut atteindre sur le réseau, y compris le NAS. Les sauvegardes sont chiffrées. Les sauvegardes n'avaient d'ailleurs jamais été testées en restauration — on savait qu'elles "tournaient" parce que le voyant était vert.
Ces deux situations ne sont pas des cas extrêmes. Elles sont représentatives de ce qu'on retrouve dans les structures qui ont traité la cyber comme une case à cocher plutôt que comme une contrainte d'architecture. La différence entre elles et celles qui s'en sortent mieux n'est pas une question de budget — c'est une question d'ordre : est-ce qu'on a pensé à ça avant ou après ?
L'argument économique est simple, et je le pose clairement : une fuite de données ou un ransomware coûte en moyenne dix fois plus cher à colmater qu'à prévenir [chiffre issu d'estimations sectorielles — à consolider avec un cas réel si possible]. Le coût de prévention, c'est du temps de conception. Le coût de correction, c'est du temps de conception plus la gestion de crise, la communication, les pertes d'exploitation, les obligations réglementaires, et parfois des sanctions. NIS2, la directive européenne sur la sécurité des réseaux et des systèmes d'information, renforce ces obligations pour un périmètre de plus en plus large — et ce n'est pas une contrainte administrative de plus, c'est la traduction légale d'un constat que le terrain fait depuis des années.
La cyber comme point de départ architectural. Ce que ça veut dire concrètement.
"Point de départ architectural" — ça peut sonner comme une formule. Laissez-moi rendre ça concret.
Quand j'arrive sur un projet, la question de sécurité n'arrive pas à la fin du diagnostic. Elle est dans le diagnostic. Pas comme un module séparé, pas comme une liste de contrôles à parcourir en fin de réunion — comme une contrainte qui conditionne toutes les décisions d'architecture qui suivent. Comment le réseau est segmenté. Où vivent les secrets. Qui peut s'authentifier depuis où. Qu'est-ce qu'on conserve, pendant combien de temps, et avec quelle garantie de restauration.
Ce qu'on pose avant le premier déploiement métier
- Segmentation réseau dès le schéma initial. Les postes de travail ne voient pas directement les serveurs applicatifs. Les serveurs applicatifs ne voient pas directement la base de données. Chaque couche est isolée. Ce n'est pas compliqué — mais ça se fait au départ, pas après.
- Secrets en coffre-fort, jamais en dur dans le code. HashiCorp Vault, Bitwarden Secrets, 1Password Secrets Automation — le choix dépend de la taille de la structure et de la souveraineté souhaitée. Ce qui ne change pas : une clé API ou un mot de passe base de données ne traîne jamais dans un fichier
.envcommité, jamais en clair dans un script. - MFA partout, par défaut. Pas en option pour les utilisateurs "avancés". Pour tout le monde, dès le premier accès. L'authentification à deux facteurs n'empêche pas tout, mais elle ferme la porte à l'écrasante majorité des attaques par credential stuffing.
- MDM sur les postes, chiffrement disque activé. Un poste perdu ou volé ne doit pas être une catastrophe de données. Le Mobile Device Management permet aussi de patcher à distance, de révoquer des accès, de voir ce qui tourne. Ce n'est pas de la surveillance — c'est de l'hygiène.
- Journaux centralisés, pas distribués. Quand quelque chose se passe, on doit pouvoir reconstruire la chronologie. Les logs éparpillés sur dix serveurs différents ne permettent pas ça. Un SIEM maison avec Wazuh ou Elastic coûte du temps de mise en place — et des heures de travail en cas d'incident.
- Backups testés ET restaurés régulièrement. Pas "configurés". Pas "actifs". Testés en restauration sur un environnement de test, avec un procès-verbal, à une fréquence définie. Un backup dont on n't a jamais vérifié la restauration n'est pas un backup — c'est un espoir.
Cette liste n'est pas exhaustive. Elle représente le socle minimal que j'exige avant de passer à la couche métier d'un projet. Ce n'est pas négociable — pas parce que je suis rigide, mais parce que construire au-dessus de fondations fragiles, c'est condamner le reste à être fragile aussi.
Dans la méthode ComiPi : l'audit cyber est dans le diagnostic. Pas en option.
La méthode que j'applique est en quatre étapes : écouter, concevoir, mettre en production progressivement, transmettre. La cyber intervient dès la première : quand j'écoute, je regarde aussi comment l'information est protégée, comment les accès sont gérés, ce qui se passerait si un poste était compromis demain matin.
Ce n'est pas un audit de sécurité au sens formel du terme — je ne suis pas certifié pentesteur. C'est un regard d'architecte sur la structure d'ensemble : les points de défaillance évidents, les zones d'ombre, les dépendances qui n'ont pas été pensées comme telles. Quand j'identifie des risques techniques, je les nomme, je les documente, et ils font partie du plan de conception qui suit.
L'avantage de cette posture pour le client est simple : ce qu'on construit ensemble est natif sur le plan de la sécurité. Pas raccommodé. La conformité RGPD n'est pas une couche qu'on plaque sur une architecture existante — elle est dans la conception de la base de données, dans la durée de rétention des logs, dans la façon dont les consentements sont stockés. La conformité NIS2, pour les structures qui y sont assujetties, devient accessible parce que les fondations l'ont anticipée.
Souveraineté et sécurité : la double protection.
Il y a un lien que je fais systématiquement dans mes diagnostics et que beaucoup de prestataires ne font pas : le lien entre souveraineté technique et sécurité des données. Ce sont deux faces du même problème.
Quand les données d'une structure sont hébergées chez elle — sur des serveurs qu'elle contrôle, avec des sauvegardes qu'elle gère, sur une infrastructure qu'elle comprend — elle bénéficie de deux protections simultanées. La première est évidente : elle sait où sont ses données, qui y a accès, et elle peut en vérifier l'intégrité à tout moment. La seconde est moins souvent formulée : elle n'est pas exposée aux clauses contractuelles d'un SaaS qui peut changer ses conditions d'accès, être racheté, ou faire l'objet d'une injonction légale dans une juridiction étrangère.
C'est pour ça que dans la démarche ComiPi, l'hébergement chez le client n'est pas un caprice technique ni une posture idéologique anti-cloud. C'est une décision d'architecture qui sert à la fois la sécurité opérationnelle et l'indépendance à long terme. Les deux ensemble — pas l'un ou l'autre. J'en parle plus en détail dans l'article sur la posture générale de ComiPi depuis 1999.
Le piège des prestataires "qui s'occupent de tout".
Il y a une phrase que j'entends régulièrement dans les premières réunions avec des clients qui ont déjà un prestataire informatique en place : "On a quelqu'un qui s'occupe de tout ça." Ça peut être vrai. Et ça peut être très faux — avec le client qui n'a aucun moyen de faire la différence jusqu'au jour où quelque chose se passe.
Anecdote plausible à valider
Un dirigeant de PME me contacte après un incident. Son prestataire "gérait la sécurité". Ce que ça voulait dire concrètement : il avait installé un antivirus sur les postes et activé le pare-feu Windows. Pas de MFA. Pas de segmentation réseau. Les sauvegardes sur un NAS en réseau — chiffré avec le reste lors de l'incident. Quand le dirigeant a demandé à voir les logs pour comprendre ce qui s'était passé, il n'y en avait pas de centralisés. Le prestataire ne savait pas non plus par où l'attaque était entrée.
"Qui s'occupe de tout" est une phrase qui doit déclencher des questions précises. Pas par méfiance systématique envers les prestataires — il y en a d'excellents. Mais parce que la sécurité informatique n'est pas un état qu'on atteint une fois pour toutes. C'est une posture continue, qui s'adapte aux menaces, aux usages, aux évolutions de la structure. Un prestataire qui "s'occupe de tout" sans que le client comprenne ce qu'il fait et comment c'est organisé, c'est une dépendance opaque — et une dépendance opaque est une vulnérabilité en soi.
Ce que je cherche à faire dans chaque mission, c'est que la structure comprenne ce qu'elle a mis en place. Pas qu'elle devienne experte en sécurité réseau — mais qu'elle sache poser les bonnes questions, qu'elle comprenne pourquoi telle ou telle mesure existe, et qu'elle ne soit pas aveugle face à son propre prestataire. L'objectif explicite de la méthode ComiPi : que la structure puisse faire sans moi dans trois ans, parce qu'elle comprend ce qu'elle a construit et pourquoi.
C'est d'ailleurs directement lié à l'architecture Dolibarr + application métier que je décris dans l'article sur pourquoi Dolibarr moche + une application UX bien pensée, c'est l'architecture qui tient en 2026. La maîtrise du socle technique — savoir ce qu'il y a en dessous, pouvoir l'auditer, pouvoir changer de prestataire sans tout perdre — c'est exactement le même principe appliqué à la sécurité.
Ce que ça change, concrètement.
Une structure qui a traité la cyber comme un point de départ architectural n'est pas une forteresse imprenable. Elle est honnête sur ce qu'elle sait protéger et sur ce qu'elle ne peut pas contrôler. Elle a des procédures de réponse à incident, même basiques. Elle sait où sont ses données critiques, qui y a accès, et elle peut répondre à ces questions en moins d'une heure si quelqu'un lui demande.
Concrètement, ça se traduit par plusieurs avantages que j'observe dans les structures qui ont cette posture. Premièrement, les certifications et audits externes deviennent simples : quand un client ou un partenaire demande une preuve de conformité, les éléments sont déjà là — pas à reconstituer en urgence. Deuxièmement, la conformité RGPD n'est pas un projet à part — elle est dans l'architecture depuis le début, ce qui évite les migrations coûteuses quand un DPO ou un auditeur se penche sur le sujet. Troisièmement, les équipes dormvent mieux — ce n'est pas une métaphore. Le dirigeant qui sait que ses sauvegardes ont été testées en restauration le mois dernier, que ses accès sont protégés par du MFA, et que ses journaux permettent de reconstruire ce qui se passe a un rapport différent au risque informatique. Il peut se concentrer sur son métier.
Ça ne coûte pas plus cher de faire les choses dans cet ordre. Ça coûte moins cher — parce qu'on ne paie pas deux fois : une fois pour construire, une fois pour reconstruire après un incident qui aurait été évitable.
Dans la même réflexion
- 1999 → 2026 : ce que j'ai mis 25 ans à mettre en musiqueLe manifeste ComiPi. La conviction fondatrice, l'histoire qui l'ancre, et pourquoi l'IA a rendu tout ça possible à grande échelle.
- Dolibarr moche + app UX : l'architecture qui tient en 2026Pourquoi séparer le socle légal de l'expérience utilisateur est une décision d'architecture, pas un compromis — et comment ça se conçoit dès le départ.
- Discuter d'un diagnosticSi vous avez des doutes sur la façon dont votre infrastructure est protégée, ou si un projet est en cours et la sécurité n'a pas encore été sérieusement posée, contactez-moi avant la livraison.
Un projet en cours ?
Avant la livraison, c'est le bon moment.
Si un projet est en production ou sur le point de l'être, et que la sécurité n'a pas été pensée en amont — il est encore temps. Un diagnostic rapide vaut mieux qu'un incident.
La méthode complète
Le blog ComiPi
Architecture, open source, automatisation, terrain. Des articles quand il y a quelque chose à dire — pas une newsletter quotidienne.