Le code écrit par votre IA est-il sûr, et conforme, à livrer ?

Le « vibe coding », décrire ce que vous voulez et laisser un agent d’IA écrire l’essentiel du code, est désormais la façon dont une grande part du logiciel se construit. Cursor, Claude Code et Copilot rendent ça rapide. Mais la vitesse a déplacé le risque : vous livrez maintenant du code que vous n’avez pas lu ligne à ligne, en production, souvent à des personnes dans l’Union. Trois problèmes se cachent dans cet écart, et le troisième est celui que presque aucune équipe ne vérifie.

Ceci est une liste de contrôle pratique avant livraison pour le code généré par IA : quoi vérifier, et où le règlement sur l’IA (règlement (UE) 2024/1689) s’applique réellement. C’est un point de départ, pas un conseil juridique.

La nouvelle surface de risque : du code que vous n’avez pas écrit, livré quand même

Des études indépendantes en 2025-2026 dressent un tableau cohérent : une large fraction du code généré par IA part avec des failles de sécurité, les commits assistés par IA fuient des secrets à un rythme mesurablement plus élevé, et les analyses d’applis nées du « vibe coding » font régulièrement apparaître des clés exposées et des flux de données non protégés. Rien de tout cela n’est un argument contre le code par IA, c’est un argument pour un contrôle dans la boucle, parce que l’étape de relecture humaine qui attrapait ces choses est exactement celle que le « vibe coding » retire.

Avant de livrer une fonction que votre IA a écrite, trois contrôles comptent.

1. Fuites de secrets et de données sensibles

Les agents d’IA inline volontiers des clés d’API, collent de vraies chaînes de connexion dans les exemples, et acheminent des données à caractère personnel (y compris des données de santé) vers des invites de modèles, des magasins vectoriels et des journaux, de nouveaux puits pour lesquels les outils historiques de prévention des fuites n’ont jamais été conçus. Attrapez-le au moment du commit, pas après une violation :

• Scannez les diffs à la recherche de secrets avant chaque poussée (un crochet avant commit, ou un seuil en CI).
• Surveillez les données à caractère personnel qui circulent vers les invites, les API d’IA de tiers et les journaux, ces flux peuvent porter des obligations RGPD indépendamment du règlement sur l’IA.

2. Contamination de licence et provenance

Les modèles d’IA sont entraînés sur du code public sous de nombreuses licences. Un extrait généré peut reproduire du code sous licence copyleft (par exemple GPL) sans attribution, et dans certaines équipes cela a voulu dire des réécritures forcées tard dans une livraison. Avant de livrer, demandez : est-ce que je sais d’où vient ce code, et puis-je le licencier comme je le livre ? La provenance devient le risque silencieux, déjà ressenti, du code généré par IA.

3. Le règlement sur l’IA, l’obligation que le « vibe coding » rate le plus souvent

Voici la part que les équipes sautent systématiquement : si votre fonction d’IA atteint des personnes dans l’Union, le règlement sur l’IA peut vous imposer des obligations, et le fait qu’une IA ait écrit votre code n’est pas le déclencheur. Ce que la fonction d’IA fait est le déclencheur.

• Transparence (article 50). L’IA exposée aux personnes, agents conversationnels, contenu généré par l’IA, hypertrucages, reconnaissance des émotions, doit indiquer que les personnes interagissent avec une IA ou en voient le résultat. Ces devoirs de transparence s’appliquent depuis le 2 août 2026.
• Systèmes à haut risque (annexe III). L’IA utilisée dans des domaines tels que l’emploi, le crédit, l’éducation ou les infrastructures critiques porte les obligations les plus lourdes (gestion des risques, gouvernance des données, contrôle humain, documentation technique). Après le Digital Omnibus, elles s’appliquent à compter du 2 décembre 2027 pour les systèmes autonomes de l’annexe III, et du 2 août 2028 pour les systèmes intégrés de l’annexe I.
• Les modèles d’IA à usage général portent des obligations depuis le 2 août 2025 ; les pratiques interdites (article 5) depuis le 2 février 2025.

Pas sûr que le règlement vous concerne, ni à quel palier de risque ? Lancez le vérificateur d’applicabilité du règlement sur l’IA, gratuit et sans compte, ou l’évaluation gratuite au titre du règlement sur l’IA : les deux vous donnent un résultat cité en quelques minutes. Pour le tableau complet, le guide du règlement sur l’IA couvre chaque article clé en langage clair.

Une liste de contrôle de 5 minutes avant de livrer une fonction générée par IA

• Secrets : aucune clé, jeton ou chaîne de connexion réelle dans le diff.
• Flux de données : aucune donnée à caractère personnel / de santé acheminée vers des invites, des API d’IA de tiers, des magasins vectoriels ou des journaux sans base juridique.
• Licences : vous savez rendre compte d’où vient le code généré, et le livrer sous votre licence.
• Applicabilité du règlement sur l’IA : vous avez classé si la fonction déclenche le règlement, et à quel palier. (Le contrôler →)
• Transparence (art. 50) : l’IA exposée aux personnes indique qu’il s’agit d’une IA.
• Un dossier : vous tenez un dossier daté, cité, de ce qui précède, que vous pouvez montrer à un collègue, un client ou un auditeur.

Ce dernier point est celui qui transforme « on pense que ça va » en quelque chose que vous pouvez réellement défendre.

Placez le contrôle là où vous codez déjà

Le faire à la main sur chaque demande de fusion ne tient pas à l’échelle. Legalithm exécute le contrôle au titre du règlement sur l’IA dans votre boucle de développement : un CLI gratuit, à code source ouvert, un serveur MCP hors ligne pour Cursor et Claude Code, et une GitHub Action. Il classe le palier de risque avec l’article cité, génère l’information de l’article 50, et écrit un dossier daté compliance/legalithm.json dans votre dépôt, revérifié en CI :

npx legalithm setup   # brancher Cursor, Claude Code et la CI
npx legalithm init     # classer et écrire le dossier cité, daté
npx legalithm check    # faire échouer la compilation en cas de dérive

Voir la documentation développeurs pour démarrer dans votre éditeur. Le volet compagnon, le règlement sur l’IA s’applique-t-il aux applis nées du « vibe coding » ?, situe le palier ; celui-ci est la liste de contrôle avant mise en production.

Limites honnêtes

Legalithm détecte des motifs et cite l’article auquel il a fait correspondre ; lorsqu’il n’est pas certain, il signale le résultat pour une revue humaine au lieu de deviner. C’est un point de départ cité, qui vous dit quand faire intervenir une personne qualifiée. Ce n’est pas un conseil juridique, et pas une certification. Pour les systèmes à haut risque et les cas limites, faites intervenir une personne compétente, le sens du contrôle est de vous dire quand.

Au fond : le « vibe coding » est là pour rester, et il est réellement productif. La discipline qui le garde sûr est un contrôle rapide, automatique, dans la boucle, pour les secrets, pour la provenance, et pour les obligations du règlement sur l’IA que la vitesse rend faciles à manquer.