La gouvernance à la vitesse de l’IA : comment le DevGovOps comble l’écart de conformité DORA

Qu’est-ce que le DevGovOps ?

Le DevGovOps est une pratique d’ingénierie de la chaîne d’approvisionnement logicielle qui intègre la gouvernance et la conformité continues dans le cycle de vie de livraison de logiciels DevOps. Plutôt que de traiter la conformité comme un obstacle manuel et rétrospectif, le DevGovOps garantit que l’application des politiques, l’auditabilité continue et la traçabilité cryptographique sont des résultats naturels de chaque version. En passant de contrôles ponctuels à une preuve continue, le DevGovOps permet aux organisations de maintenir une chaîne de traçabilité vérifiable sur leurs logiciels. Cette pratique permet aux équipes de gouverner à la vitesse du développement piloté par l’IA tout en satisfaisant à des exigences réglementaires strictes comme le Cyber Resilience Act (CRA) et le NIST SSDF.

 

À mesure que les agents de codage IA autonomes passent de la génération de suggestions d’autocomplétion à l’écriture, à la compilation, au test et au déploiement de pipelines logiciels complets, le lien entre l’intention humaine et les fichiers binaires de production se fracture. Cela a créé un déficit structurel important : nos pipelines logiciels fonctionnent à la vitesse de la machine, mais nos cadres de gouvernance, gestion des risques et conformité (GRC) progressent toujours à un rythme humain.

Combler ce déficit nécessite plus que l’adaptation a posteriori d’outils de sécurité hérités. Cela exige une discipline d’ingénierie et d’exploitation dédiée et indépendante : le DevGovOps (Development Governance Operations).

Chaque ère de livraison de logiciels a exigé une nouvelle discipline pour répondre à ses contraintes.

 

Discipline	Unit	Le shift auquel elle a répondu	Le résultat
DevOps	Dev + Ops	Les passages de relais en silos nuisaient à la vitesse d’exécution	CI/CD, tests automatisés, livraison rapide
DevSecOps	Dev + Sécurité + Ops	Les déficits et le rythme lent nuisaient à la vitesse	Analyse de sécurité dans le pipeline CI/CD
DevGovOps	Dev + Gouvernance + Ops	La gouvernance ne peut pas être rétrospective	La gouvernance comme résultat naturel du pipeline

 

Tout comme le DevOps a uni le développement et les opérations, et que le DevSecOps a intégré la sécurité dans le pipeline, le DevGovOps comble le déficit entre l’ingénierie, la sécurité et la gouvernance. Il s’agit d’une pratique collaborative : l’AppSec définit les politiques de sécurité et de gouvernance, et l’ingénierie intègre directement ces politiques dans les pipelines qu’elle gère. Cela garantit que les logiciels sont non seulement sécurisés et répondent aux critères de performance, mais qu’ils sont également continuellement conformes.

Un cas d’utilisation particulièrement pertinent du DevGovOps est la conformité continue avec le dernier règlement européen sur la résilience opérationnelle numérique (DORA), ce qui représente une réalité bien concrète pour les institutions financières et les éditeurs de logiciels qui les fournissent dans toute l’Union européenne.

La conformité DORA a été fondée sur l’hypothèse que chaque modification en production remonte à un être humain pouvant être nommé, interrogé et tenu pour responsable. Les agents de codage IA ont brisé cette hypothèse. La plupart des institutions financières n’ont pas encore rattrapé leur retard.

Lors d’un récent webinaire JFrog, nous avons expliqué pourquoi ce déficit existe, ce qu’il coûte et démontré comment le combler. Bien que le webinaire se soit concentré sur les mesures immédiates et pratiques visant à résoudre les défis de gouvernance à l’aide de la plateforme JFrog, ces défis mettent également en évidence la transition accélérée vers la reconnaissance du DevGovOps comme un élément essentiel des opérations de développement logiciel.

Pourquoi la phase d’application de DORA change tout

Les régulateurs ne demandent plus si vous avez un cadre. Ils demandent six mois d’attestations documentées.

Les régulateurs demandaient auparavant si vous disposiez d’un cadre. Aujourd’hui, ils exigent six mois d’attestations documentées.

Lorsque le règlement DORA (règlement UE 2022/2554) est entré en vigueur en janvier 2025, les régulateurs acceptaient initialement des attestations périodiques et des examens ponctuels des politiques comme preuves de contrôle. Cette phase est terminée. Les autorités nationales compétentes (ANC) à travers l’UE exigent désormais la preuve que les contrôles ont fonctionné en continu au cours des six derniers mois.

Les agents de codage IA valident, génèrent et promeuvent des artefacts 10 à 50 fois plus rapidement que le développement traditionnel basé sur des sprints. À ce volume et à cette vitesse, les décisions non documentées s’accumulent plus vite que les examens rétroactifs ou les évaluations trimestrielles ne peuvent les traiter.

Le déficit de preuve est mesurable. Selon l’état des lieux de la sécurité de la chaîne d’approvisionnement logicielle 2026 de JFrog :

• 35 % du nouveau code d’entreprise est déjà généré ou assisté par l’IA.
• Les organisations gèrent 47 % de packages d’IA de plus par an qu’il y a douze mois.
• 59 % des organisations déclarent disposer d’une visibilité complète sur la provenance en production.
• Pourtant, 48 % ont encore besoin d’une semaine ou plus pour fournir une preuve d’audit de conformité sur demande.
• Seuls 6 % peuvent le faire en moins d’un jour.

Ce déficit entre la formulation des affirmations et leur preuve est précisément là où intervient le DevGovOps, en fournissant une attestation continue de chaque artefact et processus de la chaîne d’approvisionnement.

Comment le DevGovOps comble-t-il le déficit de conformité en matière d’IA dans DORA ?

Cinq déficits de conformité reviennent systématiquement au sein des institutions financières utilisant des pipelines agentiques. Chacun correspond directement à une obligation DORA et à la manière dont un programme DevGovOps efficace permet d’y répondre.

 

Pilier DORA	Le déficit causé par le développement agentique	L’approche DevGovOps
Gestion des risques TIC (Art. 8)	Les agents d’IA extraient des bibliothèques non documentées depuis npm, PyPI ou Maven sans examen des politiques, créant des actifs TIC non surveillés.	Contrôle d’ingestion automatisé : Le pipeline intercepte et bloque automatiquement les artefacts non conformes au niveau de la passerelle, en enregistrant l’évaluation de la politique dans votre système d’enregistrement.
Gestion du changement (Art. 9)	Les commits sont poussés par des systèmes automatisés sans aucun décideur humain, ce qui rompt la chaîne de responsabilité.	Attestations cryptographiques : Chaque promotion de version est signée avec des métadonnées infalsifiables détaillant la porte policy-as-code qui l’a autorisée.
Gestion des vulnérabilités	Les scanners traditionnels ne détectent pas les failles spécifiques aux LLM, les erreurs logiques d’API et l’injection de packages malveillants.	Garde-fous de politique contextualisés : Vérifie les artefacts bloqués en fonction de la sévérité des CVE, du risque lié aux licences et du score contextuel, en détectant les déficits que les scanners post-déploiement découvrent trop tard.
Risque lié aux tiers (Art. 28 à 44)	Les modèles d’IA externes, les points de terminaison SaaS et les registres de packages sont accessibles de manière dynamique, sans intégration formelle des fournisseurs.	Système d’enregistrement unifié : Chaque dépendance, y compris les composants de modèles d’IA et les composants du registre MCP, est capturée dans un SBOM généré en continu, vous offrant un inventaire en temps réel et auditable de votre empreinte TIC tierce.
Signalement d’incidents	Lorsqu’un incident se produit, l’équipe de sécurité ne peut pas retracer rapidement quel agent d’IA, prompt ou modèle a généré le code vulnérable.	Contexte d’application et provenance : chaque version est reliée à son historique de génération et à son contexte d’application, ce qui permet à l’équipe de sécurité de cartographier le rayon d’impact et la responsabilité humaine en quelques minutes.

 

Aucun de ces écarts ne se résorbe de lui-même. Pour les combler, il faut intégrer la gouvernance dans le pipeline, et non la corriger par la suite. C’est ce que signifie le DevGovOps en pratique.

À quoi ressemble un véritable échec de gouvernance ?

Une société d’investissement nordique a déployé un agent de codage IA pour accélérer la livraison. En 90 jours, l’agent a ajouté 67 nouvelles dépendances open source à sa base de code de production. Aucune n’a été évaluée par rapport à la politique DORA de l’entreprise ni soumise à un point de contrôle par rapport à son registre des risques liés aux tiers. Lorsqu’un examen de contrôle est intervenu, il n’y avait aucune trace d’une quelconque décision prise concernant les dépendances. La remédiation a pris quatre semaines et a retardé le lancement d’un produit.

La responsabilité de ces 67 packages est restée exactement là où elle a toujours été : auprès des équipes de développement, de sécurité et de conformité. L’agent a produit le risque. Les humains en étaient responsables.

Trois principes du DevGovOps pour la gouvernance DORA à une vitesse agentique

La période de tolérance de la supervision est terminée. Voici les principes fondamentaux du DevGovOps, où la gouvernance est intégrée au cycle de vie du développement plutôt qu’assemblée après coup.

Dans le cadre de la réglementation DORA, ces principes deviennent essentiels plutôt qu’optionnels :

1. Les politiques sont du code, pas des documents : les règles de gouvernance doivent être versionnées, révisées et applicables de manière automatisée par le pipeline lui-même. Une politique qui réside dans un document Word ne peut pas être liée à un artefact spécifique ni être récupérée par un régulateur à la demande.
2. La gouvernance s’exécute à la vitesse du pipeline – Les contrôles bloquants doivent s’exécuter à chaque commit, de manière synchrone, sans délai manuel. Les examens manuels et les évaluations trimestrielles ne peuvent pas égaler la vitesse agentique. Si vos contrôles ne s’exécutent pas à la vitesse de votre pipeline, ils ne s’exécutent pas du tout.
3. Les preuves sont automatiques, pas assemblées : des enregistrements immuables et horodatés doivent être générés à chaque exécution comme sous-produit de la livraison. Les preuves rassemblées après coup ne sont pas les mêmes que les preuves qui existaient lorsque la décision a été prise.

Le déficit est là. La question est de savoir quand le combler.

Bien que les principes ci-dessus fournissent un cadre théorique pour le DevGovOps, leur mise en œuvre nécessite les bons outils. Lors de notre récent webinaire DORA à l’ère de l’IA, nous avons montré comment la plateforme JFrog fonctionne comme un système d’enregistrement unique pour mettre ces principes en pratique. En utilisant JFrog Curation et JFrog AppTrust, nous avons démontré comment bloquer automatiquement les packages malveillants dès l’ingestion, appliquer des portes policy-as-code et recueillir les preuves cryptographiques nécessaires pour vous garder constamment prêt pour les audits.

Si vous exécutez des agents d’IA dans votre pipeline et que votre gouvernance n’a pas suivi, le prochain examen de contrôle identifiera ce déficit. Les organisations qui le comblent dès maintenant, en intégrant la gouvernance dans le pipeline plutôt qu’en effectuant des audits autour de celui-ci, se trouveront dans une position fondamentalement différente lorsque cet examen arrivera.

 

---

Foire aux questions

Qu’est-ce que la loi DORA et à qui s’applique-t-elle ?

Le règlement DORA (règlement UE 2022/2554) est une loi européenne contraignante qui a pris effet en janvier 2025. Il s’applique aux institutions financières exerçant leurs activités dans l’Union européenne ou au service de celle-ci, notamment les banques, les assureurs, les sociétés d’investissement et les prestataires de services de paiement, ainsi qu’aux prestataires tiers de TIC qui les fournissent. Ses cinq piliers couvrent la gestion des risques liés aux TIC, la notification des incidents, les tests de résilience, les risques liés aux tiers et le partage d’informations.

DORA s’applique-t-il aux éditeurs de logiciels hors de l’UE ?

Oui. Si vos logiciels ou services sont utilisés par des institutions financières réglementées par l’UE, vous entrez dans le champ d’application de DORA relatif aux prestataires tiers de TIC en vertu des articles 28 à 44, quel que soit le pays du siège social de votre entreprise. Tout fournisseur de la chaîne d’approvisionnement logicielle d’une institution financière de l’UE devrait examiner ses obligations liées au DORA, notamment en ce qui concerne les exigences contractuelles, les droits d’audit et la transparence de la chaîne d’approvisionnement.

Quelles sont les sanctions en cas de non-conformité au règlement DORA ?

Les institutions financières reconnues non conformes s’exposent à des amendes allant jusqu’à 2 % de leur chiffre d’affaires annuel mondial total. Les fournisseurs tiers de TIC critiques peuvent encourir des pénalités allant jusqu’à 5 millions d’euros. Au-delà des sanctions financières, les régulateurs peuvent exiger des entreprises qu’elles suspendent ou résilient leurs contrats avec des prestataires TIC non conformes, faisant de l’exposition à DORA un risque commercial majeur, et pas seulement un risque de conformité. (Remarque : la structure exacte des pénalités peut varier selon l’application par chaque État membre ; consultez toujours un conseiller juridique.)

Pourquoi les agents de codage IA créent-ils un problème spécifique de conformité DORA ?

DORA a été conçu autour de processus de développement contrôlés par l’humain où chaque modification remonte à une personne nommée et responsable. Les agents de codage IA rompent cette chaîne de responsabilité en validant, créant et promouvant des artefacts de manière autonome. Ils récupèrent des dépendances sans examen des politiques, génèrent du code présentant des classes de vulnérabilités que les scanners traditionnels ne détectent pas et ne produisent aucune piste d’audit par défaut, ce qui empêche les organisations de satisfaire à la demande aux exigences de preuve de DORA.

Qu’est-ce que le DevGovOps et comment répond-il à DORA ?

Le DevGovOps est une pratique d’ingénierie de la chaîne d’approvisionnement logicielle qui intègre la gouvernance et la conformité continues dans le cycle de vie de livraison de logiciels. Plutôt que de rassembler des preuves de conformité a posteriori, le DevGovOps génère des attestations cryptographiques, applique des portes policy-as-code et maintient un système d’enregistrement unifié automatiquement à chaque étape du pipeline. Pour DORA en particulier, cela garantit que les preuves exigées par les régulateurs existent au moment où chaque décision est prise, et non des semaines plus tard.

Combien de temps faut-il pour produire des preuves d’audit DORA avec et sans DevGovOps ?

Selon l’état des lieux de la sécurité de la chaîne d’approvisionnement logicielle 2026 de JFrog, 48 % des organisations ont besoin d’une semaine ou plus pour fournir une preuve d’audit de conformité sur demande, et seulement 6 % peuvent le faire en moins d’une journée. Avec une approche DevGovOps, les preuves sont générées automatiquement à chaque exécution de pipeline et sont récupérables à la demande, remplaçant les exercices d’assemblage manuel de plusieurs semaines par des preuves qui existent déjà.

---

Pour en savoir plus sur le DevGovOps et découvrir ce qu’est la gouvernance continue dans la pratique, consultez la page jfrog.com/learn/grc/devgovops.