La CNIL vient de rappeler un truc simple: la cyber, ce n’est pas “optionnel” dans le public
Le 9 novembre 2026, la CNIL a annoncé avoir prononcé dix sanctions “simplifiées” visant des collectivités territoriales et un établissement public, pour des manquements de cybersécurité. Montants: 3 000 à 20 000 euros, avec 20 000 euros comme plafond légal dans cette procédure. Source: CNIL.
Le montant peut sembler “gérable”. Le signal, lui, ne l’est pas. La CNIL dit consacrer en 2026 la moitié de ses contrôles et actions répressives à la sécurité des données et elle précise qu’elle va continuer les vérifications, y compris chez les prestataires. Donc si tu vends de l’IA au secteur public en Auvergne-Rhône-Alpes, ce n’est pas juste l’acheteur qui doit être carré. C’est toi aussi.
Ce papier te fait gagner du temps côté achats et delivery: quels manquements reviennent, comment ça se traduit dans un marché public IA, et quels dossiers tu dois avoir prêts avant même de répondre à un appel d’offres.
Ce que la CNIL a sanctionné, concrètement: les mêmes basiques qui lâchent
Les décisions CNIL pointent des failles qui ne sont pas “exotiques”. C’est de l’hygiène. Et c’est exactement ce qui casse les projets IA quand tu branches un nouvel outil sur un SI de collectivité.
1) Authentification distante: pas de MFA sur des comptes à privilèges
La CNIL cite l’absence d’authentification multifacteur pour des comptes privilégiés, notamment des administrateurs en accès distant (télétravail). Source: CNIL.
Traduction IA: si ton produit nécessite un accès admin au tenant M365, à un annuaire, à une base, à une infra on-prem, ou si tu fais de la télémaintenance, l’acheteur va te demander comment tu blindes ça. Et il aura raison.
2) Accès prestataires trop ouverts: permanent, comptes partagés, pas de cadrage
La CNIL vise des prestataires pouvant accéder au réseau de manière permanente, sans autorisation au cas par cas, et/ou via des comptes partagés. Source: CNIL.
Traduction IA: ton mode “support” classique (un VPN qui traîne, un compte “support@”, un accès qui reste après la mise en prod) devient un risque contractuel. Et un risque CNIL pour ton client. Donc un risque commercial pour toi.
3) Journalisation et détection: logs incomplets ou inutilisés
La CNIL parle de journaux incomplets ou non exploités “en temps réel ou à court terme”. Source: CNIL.
Traduction IA: si tu vends une brique GenAI (assistant, agent, RAG) qui touche aux données et aux identités, on va te demander: qui s’est connecté, quand, depuis où, et qu’est-ce qui a été fait. Et si tu ne sais pas répondre, tu vas perdre le marché ou te faire verrouiller par des exigences tardives.
4) Cloisonnement réseau: segmentation insuffisante
La CNIL relève un cloisonnement trop faible, avec risque d’extension d’un incident à plusieurs segments. Source: CNIL.
Traduction IA: les collectivités en AuRA ont souvent des SI hétérogènes, des satellites (écoles, CCAS, médiathèques, régies), et des prestas multiples. Si ton IA demande “un accès au réseau” sans design minimal (flux, ports, zones), tu vas au clash avec la DSI et le RSSI.
5) Systèmes obsolètes: OS non maintenus
La CNIL cite des serveurs sous OS plus maintenus et donc sans correctifs adaptés. Source: CNIL.
Traduction IA: beaucoup de projets “IA métier” finissent connectés à un applicatif ancien. Si tu livres une stack qui nécessite une VM exotique, un composant EoL, ou si tu refuses de documenter ta politique de patch, tu crées une bombe à retardement que l’acheteur public ne veut plus assumer.
6) Mots de passe: faibles, transmis en clair, stockés n’importe comment
La CNIL mentionne des mots de passe faibles, transmis en clair aux usagers ou stockés sans garanties suffisantes. Source: CNIL.
Traduction IA: si tu fournis des comptes à des agents municipaux, à des élus, à des agents d’accueil, ou à des usagers via un téléservice, tu dois avoir une politique propre: création, rotation, stockage, reset, MFA, et surtout fin des comptes partagés.
7) Homologation de sécurité: oubliée avant mise en service
La CNIL relève l’absence d’homologation de sécurité avant mise en service alors que le RGS l’exige pour certains SI publics. Source: CNIL.
Traduction IA: tu peux avoir un produit excellent. Si la collectivité doit homologuer et que tu n’as pas les éléments (architecture, risques, mesures, tests), ton planning explose. Et ton CA avec.
8) AIPD: pas faite sur des traitements à risque élevé
La CNIL sanctionne aussi l’absence d’AIPD avant des traitements “à risque élevé”, citant notamment des téléservices liés à des enfants et à des coordonnées bancaires, ou de la vidéoprotection sur voie publique. Source: CNIL.
Traduction IA: si ton IA touche au social, à l’éducation, à la relation usagers, à la vidéo, à l’identification, à la santé au sens large, ou à la détection de fraude, l’AIPD va revenir sur la table. Et tu devras contribuer, même si “ce n’est pas ton job”.
Pourquoi ça change la donne pour les vendeurs et intégrateurs IA en AuRA
Les collectivités d’Auvergne-Rhône-Alpes ne sont pas toutes “grands comptes”. Mais elles ont les mêmes contraintes: RGPD, audits, exposition ransomware, et maintenant un signal CNIL très net.
Résultat côté achats: tu vas voir plus souvent ces mots dans les DCE, RC, CCTP, CCAP:
- exigences RSSI IA et questionnaires de sécurité plus longs
- clauses d’accès prestataire (nominatif, tracé, limité dans le temps)
- preuve de MFA, de journalisation, de gestion des vulnérabilités
- PRA/PCA et engagements de rétablissement
- contribution à l’AIPD et au registre de traitement
- parfois des exigences d’hébergement et de “confiance” selon sensibilité
Et côté delivery: tu vas te retrouver à faire de la cyber “dans le projet” (accès, comptes, logs, runbooks). Si tu n’as pas packagé ça, tu vas le subir en urgence.
Achats publics IA: ce que ces sanctions vont provoquer dans les exigences et clauses
Accès prestataire: fini le “on a besoin d’un compte admin pour aller vite”
Attends-toi à des demandes très concrètes:
- accès nominatif (pas de compte partagé), avec rôles séparés (admin, support, dev)
- durée limitée (JIT access), autorisation au cas par cas
- MFA obligatoire, surtout pour comptes à privilèges
- interdiction ou encadrement strict de la télémaintenance
- revue périodique des habilitations
Si tu veux être crédible, prépare une annexe “accès et télémaintenance” prête à coller dans une réponse.
Preuves plutôt que promesses: montre ce qui est vérifiable
Les manquements CNIL portent sur des mesures “auditables”. En marché public, ça veut dire: tu ne gagnes pas avec une phrase marketing, tu gagnes avec un dossier.
- extraits de politiques (accès, mots de passe, patching)
- schémas d’architecture et flux réseau
- exemples de journaux (ce qui est loggé, durée de conservation)
- procédures de gestion d’incident et délais de notification
- politique de fin de support (EoL) et de mises à jour
Journalisation: un point qui va remonter dans les critères de notation
Pour une solution IA, la journalisation ne se limite pas à “qui s’est connecté”. Il faut pouvoir expliquer:
- journaux d’authentification (succès, échecs, MFA)
- journaux d’accès aux données (lecture, export, téléchargement)
- journaux d’actions IA (quand un agent exécute une action, sur quel système)
- journaux d’admin (changement de config, création de compte)
- capacité à exporter vers le SIEM ou l’outil de la collectivité
Si tu bosses sur des agents IA, tu peux recoller avec notre angle “logs et accès avant d’automatiser” ici: https://lyon-ia.com/blog/agents-ia-et-cybersecurite-effacement-de-traces-audit-des-logs-et-acces-avant-dautomatiser.
Patching et obsolescence: ça devient une clause, pas un sujet interne
La CNIL a cité des OS serveurs obsolètes. Donc l’acheteur public va exiger:
- tes délais de correction (SLA de patch) selon criticité
- ta veille vulnérabilités et le traitement des CVE
- ton inventaire des composants (au minimum une logique SBOM “light”)
- une politique claire de montée de version et de fin de support
Si tu vends du SaaS IA, ça doit être industrialisé. Si tu vends de l’on-prem IA, ça doit être contractualisé (sinon tu te fais piéger entre “le client ne patch jamais” et “le fournisseur n’est pas responsable”).
AIPD: impact direct sur ton planning et ton “time to value”
Une AIPD mal anticipée, c’est un projet qui glisse. Dans les collectivités, ce n’est pas rare: DPO à temps partiel, RSSI partagé, prestas multiples. Donc tu dois:
- proposer un pack de contribution AIPD (mesures, risques, architecture, sous-traitants)
- clarifier où sont les données, qui y accède, et pour quoi
- documenter les durées de conservation, la purge, et les exports
Sur la partie achats, tu peux aussi t’appuyer sur la logique “répondre sans survendre” qu’on détaillait ici: https://lyon-ia.com/blog/achats-publics-dia-ce-que-change-le-guide-dinum-et-comment-repondre-sans-survendre.
Collectivités en AuRA: les contraintes terrain que tu dois intégrer (sinon tu prends le mur)
À Lyon, dans la Métropole, et plus largement en AuRA, tu retrouves souvent:
- des SI “mille-feuilles” (métier, état civil, scolaire, social, urbanisme)
- des équipes IT petites, donc un besoin de preuves simples et d’exploitation facile
- du multi-sites (mairies annexes, équipements) et des prestas en cascade
- des contraintes de continuité de service: accueil, inscriptions, régies, paie
Ton IA n’est pas un îlot. Elle va être perçue comme une nouvelle porte d’entrée. Donc tu dois arriver avec un design d’accès minimal, et une exploitation compatible avec un run municipal.
Check-list: les “dossiers” à préparer avant de vendre ou déployer une IA dans une collectivité
Objectif: être prêt à répondre vite à un questionnaire RSSI, à un DCE, ou à un contrôle. Pas avec des promesses, avec des pièces.
1) Dossier sécurité “vendeur”: PSSI, politiques, et responsabilités
- PSSI ou politique sécurité équivalente, même courte (versionnée, datée)
- organisation: qui est responsable sécu, qui est d’astreinte, qui décide
- liste des sous-traitants et ce qu’ils font (hébergeur, infogérance, outil support)
- processus de gestion d’incident (détection, escalade, notification)
2) Dossier gestion des accès: le point CNIL le plus “piégeux” pour toi
- schéma IAM: SSO possible, MFA, RBAC
- règles: pas de comptes partagés, création nominative, suppression à la fin
- accès prestataire: JIT, durée, justification, validation
- preuves: exemples de paramétrage MFA, exemples de rôles
Pour cadrer la partie “agents et accès”, tu peux recoller avec: https://lyon-ia.com/blog/securiser-un-agent-ia.
3) Dossier journalisation: ce que tu logges, combien de temps, et comment tu l’exploites
- liste des événements loggés (auth, admin, accès data, actions)
- durée de conservation et justification
- capacité d’export (format, API) vers l’outillage de la collectivité
- procédure de consultation rapide en cas d’incident
4) Dossier vulnérabilités et mises à jour: ton plan anti-obsolescence
- politique de patch (fréquence, criticité, délais)
- gestion EoL: ce que tu fais quand un composant arrive en fin de support
- hardening minimal (config sécurisée par défaut)
- preuves: changelog, notes de version, rapports de scan si tu en as
5) Dossier sauvegardes et restauration: ce qui évite la honte en comité de crise
- ce qui est sauvegardé (données, config, modèles, prompts, bases vectorielles)
- fréquence, rétention, séparation (idéalement hors domaine)
- tests de restauration documentés (pas “on sauvegarde”)
Tu veux une base simple à reprendre pour industrialiser ce point: https://lyon-ia.com/blog/automatiser-ses-sauvegardes.
6) Dossier PRA/PCA: continuité de service, pas juste “haute dispo”
- PRA: RTO, RPO, procédures de reprise, responsabilités
- PCA: mode dégradé, contournements, priorisation des fonctions
- tableau des dépendances: identité, réseau, API LLM, stockage, annuaire
Sur le volet continuité, tu peux t’inspirer d’un cas très concret “réseau qui tombe”: https://lyon-ia.com/blog/orangesosh-en-panne-a-lyon-pca-ia-automatisation-quand-le-reseau-tombe.
7) Dossier conformité RGPD et AIPD: prêt à contribuer, pas à débattre
- description du traitement: finalités, données, personnes concernées
- mesures techniques et organisationnelles: chiffrement, accès, logs
- localisation des données et transferts éventuels
- politique de conservation et purge
Si tu veux cadrer l’IA agentique côté RGPD (utile quand tu as des agents qui agissent): https://lyon-ia.com/blog/ia-agentique-et-rgpd-ce-que-la-note-cnil-change-pour-vos-agents-check-list-a-lyon.
Ce que tu changes dès maintenant dans ta manière de vendre et livrer de l’IA au public
Si tu veux rester dans la course sur “IA marché public sécurité”, fais simple et efficace.
- Packe tes preuves en amont. Un dossier sécurité réutilisable. Sinon tu réinventes tout à chaque AO.
- Standardise l’accès support. Nominatif, MFA, limité dans le temps, tracé. Tu le proposes, pas l’acheteur qui te le force.
- Rends la journalisation exploitable. Pas juste “on a des logs”. Il faut savoir les sortir vite.
- Écris noir sur blanc ta politique de patch. Et ce que tu fais quand un composant est EoL.
- Anticipe l’AIPD sur les cas à risque. Tu prépares un kit de contribution.
- Prévois le run dès l’avant-vente. Qui administre, qui valide, qui coupe, qui restaure.
Un plan d’action en 10 jours pour être “audit-ready” sur un marché IA en AuRA
- J1: inventaire de ton offre (SaaS, on-prem, hybride), des données traitées, des sous-traitants.
- J2: document “accès prestataire” (nominatif, MFA, durée limitée, procédures).
- J3: matrice rôles et habilitations (RBAC) et modèle de comptes.
- J4: plan de journalisation (quoi, où, combien de temps, export possible).
- J5: politique patch et vulnérabilités (délais, process, EoL).
- J6: sauvegardes et test de restauration (au moins un test documenté).
- J7: squelette PRA/PCA (RTO, RPO, mode dégradé).
- J8: kit AIPD (description traitement, risques, mesures).
- J9: modèles d’annexes contractuelles (sécurité, support, réversibilité).
- J10: une revue “acheteur public”: est-ce que tu peux prouver tout ce que tu affirmes en 15 minutes.
Ce qu’il faut retenir si tu vends de l’IA aux collectivités en Auvergne-Rhône-Alpes
Les CNIL sanctions collectivités cybersécurité de novembre 2026 ne racontent pas une histoire de “petites amendes”. Elles racontent un durcissement durable, avec un focus sur des basiques mesurables: MFA, accès prestataires, logs, segmentation, mises à jour, mots de passe, homologation, AIPD.
Si tu es fournisseur IA, ta marge et ta vélocité vont dépendre d’un truc: ta capacité à arriver avec un dossier propre, prêt pour un RSSI et un marché public. Pas un discours. Des preuves.
Laisser un commentaire