Le règlement sur l’IA s’applique-t-il aux applis nées du « vibe coding » ?

Vous avez décrit ce que vous vouliez, un agent d’IA a écrit l’essentiel, et vous avez livré en un week-end. Il y a maintenant un vrai public, dont une part dans l’Union, et une question qui revient : le règlement sur l’IA s’applique-t-il à quelque chose que j’ai construit en « vibe coding » ?

Réponse courte : le règlement ne tient pas compte de la façon dont vous avez écrit le code. À la main, sans code, ou en « vibe coding » avec Cursor ou Claude Code, cela ne change rien. Ce qui compte, c’est ce que fait la fonction d’IA de votre application, qui vous êtes dans la chaîne de valeur, et si des personnes dans l’Union sont concernées. Donc oui : une appli née du « vibe coding » peut être pleinement dans le champ. Voici comment situer exactement où vous en êtes.

Le mythe : « une IA a écrit mon code, donc le règlement sur l’IA s’applique »

On se trompe dans les deux sens. Se servir d’une IA pour écrire votre code n’est pas ce qui déclenche le règlement sur l’IA. Le règlement encadre les systèmes d’IA que vous mettez en service, l’agent conversationnel, le système de recommandation, le générateur de contenu, l’outil de présélection que votre application contient et livre, pas le choix de votre environnement de développement. La vraie question n’est donc pas « ai-je utilisé une IA pour la construire » mais « mon appli met-elle un système d’IA face à des personnes, et certaines d’entre elles sont-elles dans l’Union ? »

Trois questions qui décident si vous êtes dans le champ

1. Votre appli utilise-t-elle l’IA comme fonction ? Un agent conversationnel, du texte, des images ou de l’audio générés, un classifieur, un modèle de recommandation ou de notation des risques, des fonctions de reconnaissance des émotions ou biométriques : chacun de ces éléments est un « système d’IA » au sens du règlement.
2. Des personnes dans l’Union y ont-elles accès, ou à son résultat ? Le règlement vous atteint si vous mettez le système sur le marché de l’Union ou si son résultat est utilisé dans l’Union, même lorsque votre société est hors de l’Union (article 2). Livrer une application web mondiale, c’est presque toujours oui.
3. Quel est votre rôle, fournisseur ou déployeur ? Vous avez construit ou modifié de façon substantielle le système d’IA (y compris par affinage ou en encapsulant un modèle dans un produit) ? Vous êtes vraisemblablement fournisseur, avec les obligations les plus lourdes. Vous utilisez seulement le système d’IA d’un tiers dans votre produit ou vos opérations ? Vous êtes déployeur, avec des devoirs plus légers, mais réels.

Si vous avez répondu oui aux points 1 et 2, le règlement s’applique ; il ne reste qu’à savoir quel palier, et ce que cela vous coûte.

Pas sûr de votre rôle, ni du test « résultat utilisé dans l’Union » ? Lancez le vérificateur d’applicabilité du règlement sur l’IA, gratuit et sans compte : il parcourt l’article 2 en environ une minute.

Dans quel palier de risque se situe votre appli née du « vibe coding » ?

Le règlement range les systèmes d’IA en quatre paliers. La plupart des applis d’indépendants et de jeunes pousses tombent dans l’un des deux du milieu :

• Interdit. Notation sociale, systèmes manipulateurs ou qui exploitent une vulnérabilité, la plupart des identifications biométriques en temps réel dans l’espace public. Si votre projet parallèle amusant fait cela, arrêtez : ces pratiques sont interdites d’emblée (en vigueur depuis le 2 février 2025).
• Haut risque (annexe III). IA utilisée dans l’emploi et le recrutement, le crédit et le prêt, l’éducation, les services essentiels, les infrastructures critiques, les autorités répressives, et assimilés. Un outil de présélection de CV ou d’éligibilité au crédit né du « vibe coding » est à haut risque : les obligations les plus lourdes s’appliquent.
• Risque limité / transparence (article 50). Agents conversationnels, contenu généré par l’IA, hypertrucages, reconnaissance des émotions. La plupart des applis d’IA grand public vivent ici. Le devoir est l’information : indiquer aux personnes qu’elles interagissent avec une IA, et étiqueter le contenu généré ou manipulé par l’IA.
• Minimal. Filtres antispam, IA dans les jeux, la plupart des fonctions du quotidien : pas d’obligations spécifiques au-delà des bonnes pratiques générales.

Un contrôle rapide, avec des exemples :

• Un agent conversationnel d’assistance sur votre SaaS → transparence (art. 50) : indiquer que c’est une IA.
• Un générateur d’images ou de vidéos par IA → transparence : étiqueter la sortie comme générée par l’IA.
• Une IA qui présélectionne des candidatures ou note la solvabilité → haut risque : le programme complet (gestion des risques, gouvernance des données, contrôle humain, documentation technique).

Pour obtenir votre palier réel, avec l’article cité, lancez l’évaluation gratuite au titre du règlement sur l’IA : niveau de risque, obligations et références en quelques minutes, sans compte.

Les échéances (après le Digital Omnibus)

Le calendrier a bougé en 2026 ; tenez-vous-en aux dates actuelles, pas à celles de l’an dernier :

• Pratiques interdites (article 5) : en vigueur depuis le 2 février 2025.
• Obligations des modèles d’IA à usage général : depuis le 2 août 2025.
• Transparence / article 50 : s’appliquent à compter du 2 août 2026, le palier qui intéresse le plus les applis grand public.
• Haut risque (annexe III autonome) : 2 décembre 2027, après le report du Digital Omnibus (systèmes intégrés dans un produit → 2 août 2028).

Donc si votre appli née du « vibe coding » est un agent conversationnel ou génère du contenu, c’est l’échéance de transparence qui est proche. Si elle est à haut risque, vous avez jusqu’à fin 2027, mais le travail (documentation, gouvernance des données, contrôle humain) est de ceux qu’on veut construire tôt, pas greffer après coup.

Ce que vous devez réellement, selon le palier

• Palier transparence : une information claire sur l’IA, plus l’étiquetage du contenu généré par l’IA. Petit, mais réel, et facile à manquer quand on livre vite. (Legalithm peut générer l’information de l’article 50 pour vous.)
• Palier haut risque : un processus de gestion des risques, la gouvernance des données, la journalisation, le contrôle humain, et un dossier de documentation technique de l’annexe IV. C’est un programme, pas une case à cocher ; commencez le dossier maintenant.
• Fournisseur ou déployeur : les fournisseurs portent l’essentiel de ce qui précède ; les déployeurs s’assurent surtout d’utiliser le système conformément à sa destination, d’assurer un contrôle humain, et d’informer les personnes concernées. Le guide du règlement sur l’IA détaille les devoirs article par article.

Contrôlez-le là où vous construisez

Vous n’avez pas besoin d’un avocat pour savoir où vous en êtes. Legalithm exécute le contrôle au titre du règlement sur l’IA dans votre boucle de développement : un CLI gratuit, un serveur MCP hors ligne pour Cursor et Claude Code, et une GitHub Action classent votre fonction avec l’article cité et consignent un dossier daté compliance/legalithm.json dans votre dépôt :

npx legalithm setup   # brancher Cursor, Claude Code et la CI
npx legalithm init     # classer et écrire le dossier cité, daté

Voir la documentation développeurs pour démarrer dans votre éditeur, et le volet compagnon Le code écrit par votre IA est-il sûr, et conforme, à livrer ? pour la liste de contrôle complète 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, pas un conseil juridique, et pas une certification. Pour les systèmes à haut risque surtout, faites intervenir une personne compétente.

Au fond : le « vibe coding » ne vous exempte de rien. Le règlement sur l’IA suit la fonction, pas le clavier, et le plus rapide pour savoir où en est une construction d’un week-end, c’est de la contrôler dans la même boucle que celle où vous l’avez construite.