8 Min. Temps de lecture
Une plateforme de développement interne est rarement remise en question lors d’un audit, pas au niveau du code. Elle l’est au niveau de la preuve. Lorsqu’il faut démontrer lors d’un audit NIS2 que chaque déploiement a documenté le cryptage, la région et l’accès, on ne cherche pas dans les référentiels, mais sur la plateforme. C’est précisément là que se décide si la conformité reste un projet permanent ou devient une configuration que chaque équipe adopte sans s’en apercevoir.
Les points clés en bref
- La plateforme devient le levier de conformité : le cryptage, l’étiquetage, les régions autorisées et la traçabilité peuvent être appliqués en un seul endroit au lieu de l’être dans quarante référentiels séparés.
- La politique en tant que code remplace les check-lists Excel : OPA Gatekeeper et Kyverno vérifient automatiquement les configurations par rapport aux exigences NIS2, DORA et EU AI Act avant que le code ne soit déployé en production.
- L’équipe de la plateforme devient pertinente pour l’audit : qui contrôle les garde-fous contrôle la situation de conformité. Les auditeurs demanderont à partir de 2026 d’abord là, et non plus dans l’équipe de service individuelle.
Lié :L’ingénierie de plateforme n’est plus un projet DevEx / Plateforme ou façade ?
Pourquoi la conformité atterrit maintenant sur la plateforme
Qu’est-ce que l’ingénierie de plateforme signifie pour la conformité ? C’est la discipline qui consiste à ne plus vérifier les exigences réglementaires telles que NIS2, DORA ou l’EU AI Act par service, mais à les intégrer comme paramètres par défaut dans la plateforme de développement interne. Le cryptage, la journalisation, les droits d’accès et la région ne sont plus des recommandations, mais des conditions qu’un déploiement ne peut pas contourner.
Trois ensembles de règles convergent actuellement. NIS2 élargit considérablement le cercle des secteurs soumis à des obligations et place la gestion des risques, la journalisation et la déclaration d’incidents sous la responsabilité du conseil d’administration. DORA est en vigueur depuis janvier 2025 pour le secteur financier et exige non seulement une résilience propre, mais également une surveillance des fournisseurs tiers critiques. L’EU AI Act introduira des obligations de documentation et de preuve pour les systèmes à haut risque à partir d’août 2026. Trois obligations, trois délais, trois voies d’audit. Qui résout cela par référentiel ne pourra plus suivre.
C’est précisément ici que la plateforme interne s’est développée au cours des douze derniers mois, passant d’une couche de confort au lieu naturel des garde-fous. Puisque chaque déploiement passe de toute façon par elle, elle est le seul point où les règles peuvent être appliquées de manière centrale. Cette centralité est à la fois un avantage et un fardeau.
Cette simultanéité est le point décisif. Une plateforme construite comme un outil de confort pour les développeurs est confrontée en 2026 à une pratique d’audit qu’elle n’avait pas prévue. Qui construit la fonction de conformité après coup autour d’une plateforme mature risque de créer exactement les solutions isolées que la plateforme était censée supprimer.
Ce que la plateforme peut appliquer automatiquement
L’outil pratique s’appelle Policy-as-Code. OPA Gatekeeper et Kyverno sont les deux moteurs dominants dans l’environnement Kubernetes. Les deux vérifient les définitions de ressources par rapport aux règles déclarées avant qu’elles n’entrent dans le cluster. Ce qui est formulé en tant que politique s’applique automatiquement à tout le monde qui déploie via la plateforme.
Une introduction pragmatique ne commence pas par l’application, mais par la visibilité. D’abord le mode Audit, puis l’application. L’expérience de plusieurs équipes de plateforme dans la région DACH : ceux qui déploient immédiatement des politiques de blocage récoltent des contournements. Ceux qui les laissent fonctionner pendant deux à trois semaines en mode avertissement obtiennent une liste réelle des endroits où la réalité s’écarte de la règle. Cette liste vaut plus que n’importe quel protocole d’audit.
Ce qui peut être appliqué de manière judicieuse sur une plateforme s’est réduit à une liste restreinte dans la pratique.
Aucun de ces quatre garde-fous n’est techniquement particulièrement exigeant. La partie difficile est organisationnelle. Une règle qui bloque une équipe nécessite un chemin d’escalade, une exception documentée et une personne responsable. Sinon, chaque nouvelle politique crée un workflow fantôme qui contourne la plateforme exactement là où elle est censée intervenir.
Où les équipes échouent avec la plateforme de conformité
Les erreurs les plus fréquentes ne se trouvent pas dans l’engine de politique, mais dans le modèle opérationnel.
Ce qui échoue
- Des politiques qui passent directement en mode bloquant sans phase d’audit, poussant les équipes à créer des pipelines parallèles
- Des règles de conformité qui ne sont versionnées nulle part, de sorte qu’il est impossible de savoir depuis quand elles sont en vigueur lors d’un audit
- Une équipe de plateforme sans mandat, qui ne peut ni accorder ni refuser d’exceptions
- Des garde-fous qui ne couvrent que Kubernetes, tandis que les workloads critiques sont exécutés sur des services gérés
Ce qui fonctionne
- Un modèle de phases comprenant un mode audit, une période d’apprentissage documentée et une mise en vigueur progressive
- Des politiques dans Git avec une versionisation claire, un journal des modifications et un chemin de rollback
- Un chemin d’escalade avec un propriétaire de conformité responsable, qui peut accorder des exceptions avec un délai
- Un périmètre de plateforme qui dépasse Kubernetes et vérifie également les configurations de services gérés
La différence entre les deux colonnes est rarement un outil. C’est une décision sur la responsabilité. Celui qui introduit Policy-as-Code sans clarifier qui est responsable de l’exception en cas de conflit, construit une couche technique sans couverture organisationnelle.
Qui devient pertinent pour l’audit à la fin
Dès que la plateforme met en vigueur des règles que l’auditeur souhaite voir, l’équipe de plateforme fait partie de l’organisation de conformité. Elle doit être en mesure de fournir des informations sur les politiques en vigueur, les exceptions accordées, les infractions constatées et la manière dont elles ont été traitées. C’est un rôle différent de celui du prestataire de services qui entretient une expérience de développeur.
Ce changement a deux conséquences. Premièrement, l’équipe de plateforme a besoin d’une ligne de communication avec l’équipe de conformité et de protection des données, qui n’est pas créée de manière ad hoc, mais qui est établie. Deuxièmement, une partie de la responsabilité du conseil d’administration pour la gestion des risques NIS2 et la résilience DORA est structurellement transférée aux épaules qui contrôlent les garde-fous. Ce n’est pas une sanction de carrière, mais la reconnaissance honnête de ce que fait réellement une plateforme mature.
Celui qui traite encore la plateforme en 2026 comme une couche de confort, risque non seulement l’audit suivant. Il gaspille peut-être le plus grand effet de levier que les plateformes internes aient jamais eu : faire d’un ensemble de trois réglementations européennes qui se chevauchent non pas trois projets, mais une configuration.
Foire aux questions
Qu’est-ce qui distingue l’ingénierie de plateforme pour la conformité des outils GRC classiques ?
Les outils GRC documentent les règles. Une plateforme de conformité les met en œuvre. La différence se manifeste lors de l’audit : les GRC fournissent des listes de ce qui devrait s’appliquer. La politique en tant que code sur la plateforme fournit des journaux de ce qui s’est réellement produit et de ce qui a été bloqué en cas de conflit. Les deux couches se complètent, mais ne se remplacent pas.
Quel moteur de politique est le plus adapté pour commencer, OPA ou Kyverno ?
Les deux sont établis. Kyverno a une courbe d’apprentissage plus faible, car les politiques sont formulées en YAML et restent proches des manifestes Kubernetes. OPA Gatekeeper est plus puissant avec Rego et convient mieux lorsque les ressources cloud et les systèmes externes doivent également être vérifiés. De nombreuses équipes de plateforme combinent les deux en fonction du cas d’utilisation.
Comment empêcher les équipes de déployer des applications sans passer par une plateforme restrictive ?
Trois mesures aident. Premièrement : une voie d’escalade avec une personne désignée qui accorde des exceptions avec un délai et une justification. Deuxièmement : un mode d’audit avant l’application, afin que les équipes comprennent la nouvelle règle avant qu’elle ne les bloque. Troisièmement : une télémétrie sur les tentatives de contournement, afin que les pipelines fantômes soient visibles tôt.
Une plateforme de conformité suffit-elle à elle seule pour NIS2 ?
Non. NIS2 exige une gestion des risques, une déclaration d’incident et une responsabilité de la direction. La plateforme couvre la partie technique et fournit les preuves. Les processus, les responsabilités et les voies de déclaration restent dans l’organisation. La plateforme rend l’obligation de preuve plus facile à gérer qu’une collecte manuelle.
À partir de quelle taille d’entreprise une plateforme de conformité est-elle rentable ?
Le seuil se situe moins en fonction du nombre d’employés que du nombre de charges de travail productives. Dès que plusieurs équipes déploient en parallèle et que les mêmes règles doivent être appliquées à chaque service, le chemin manuel est plus coûteux qu’une plateforme centrale. Avec deux ou trois services, une liste de contrôle suffit, mais pas avec vingt.
Plus d’informations du réseau MBF Media
