Application codée avec l'IA ? Le guide Vibe Coding de la SDAIA traite chaque ligne comme un brouillon jusqu'à la revue humaine

Si votre application, votre site ou votre système interne a été construit avec des outils d'IA, ou si votre développeur les utilise, le guide « Vibe Coding » publié par l'Autorité saoudienne des données et de l'intelligence artificielle (SDAIA) en avril 2026 fixe une règle claire : tout ce que l'IA génère est un brouillon non validé tant qu'un humain ne l'a pas relu, vérifié et formellement approuvé. Le guide compte 57 pages, s'adresse aux équipes techniques du secteur public comme du secteur privé, nomme 4 risques principaux et 6 limites essentielles, et fixe 5 points où un humain doit intervenir avant que le code n'atteigne vos clients. Dans cet article, nous le traduisons en questions concrètes à poser à votre équipe ou à votre prestataire cette semaine.

Qu'est-ce que le vibe coding selon la SDAIA ?

Le guide définit le vibe coding (en arabe « al-barmaja al-tawlidiya », la programmation générative) comme une approche où l'utilisateur décrit ce qu'il veut en langage courant et où les outils d'IA écrivent le code. Il va au-delà de l'écriture, vers ce qu'il appelle l'IA agentique : des outils qui construisent le code, lancent les tests et gèrent le déploiement eux-mêmes, tandis qu'un humain oriente les décisions clés.

Le guide répartit l'usage en 3 volets : la conception et l'expérience utilisateur (idées et prototypes), la programmation (écriture et amélioration du code) et les tests (plans de test, données de test et analyse des pannes). Il cite Microsoft, selon qui ces outils génèrent environ 30 % du code produit en interne, et Google, selon qui environ 25 % de son nouveau code est généré par l'IA puis relu par des humains avant intégration. Le message est clair : les plus grandes entreprises utilisent ces outils chaque jour, mais à l'intérieur d'un système de revue.

La règle clé : la sortie de l'IA est un brouillon

La première définition du guide est le « brouillon généré par l'IA » : toute sortie du système reste un premier brouillon non validé jusqu'à sa revue humaine, sa vérification et son approbation. Il qualifie le principe « Human-in-the-loop » (l'humain dans la boucle) de principe de gouvernance obligatoire dans sa méthode. Il ajoute que l'intervention humaine devient obligatoire lorsque des outils d'IA reçoivent des droits d'exécution pouvant avoir un impact opérationnel, juridique ou commercial important.

Concrètement pour un dirigeant : si un outil d'IA peut publier une mise à jour de votre application ou modifier votre base clients sans que personne ne valide, c'est exactement ce contre quoi le guide met en garde. Précisons que le guide est indicatif, ce n'est pas un règlement assorti de sanctions, mais c'est la référence officielle saoudienne la plus claire à ce jour sur ce qu'est un « usage responsable » de ces outils, et il complète le cadre national de gestion des risques de l'IA.

4 risques nommés par le guide, et leur forme dans votre projet

• Hallucination : un code qui semble correct mais appelle des API inexistantes, ou recommande des paquets et bibliothèques fictifs ou non maintenus. Résultat : des erreurs d'intégration avec vos autres systèmes, voire une faille si quelqu'un installe un paquet suggéré sans le vérifier.
• Excès de confiance : accepter un code généré sans revue de sécurité ni revue fonctionnelle, ou le passer directement dans l'environnement de production utilisé par vos clients.
• Couverture superficielle : une analyse de sécurité générique qui laisse passer des failles, et des tests incomplets, qui donnent un faux sentiment que tout va bien.
• Sorties non déterministes : la même consigne produit un code différent à chaque fois, ce qui rend les résultats difficiles à reproduire et à auditer.

6 choses que l'IA ne garantit pas

Le guide énumère 6 limites essentielles : l'IA ne comprend l'intention de votre activité que dans la mesure où vous l'avez écrite ; elle ne sait pas évaluer les risques ou les priorités propres à votre organisation ; elle ne remplace ni la réflexion d'architecture ni les décisions de conception ; elle ne garantit pas que le code est correct ou adapté à l'usage réel ; elle ne produit pas toujours des résultats identiques ; et ses sorties ne constituent ni une preuve de test formelle ni un substitut aux vrais tests. Le guide le dit clairement : la responsabilité de la vérification, des tests et de l'approbation est « entièrement humaine ».

5 points de contrôle humain avant que le code n'atteigne vos clients

1. Relire chaque modification de code avant sa fusion dans la branche principale.
2. Évaluer la maturité de chaque version avant son déploiement.
3. Superviser la décision de déployer ou de revenir en arrière.
4. Expliquer tout comportement inattendu en production.
5. Approuver les plans de développement et la feuille de route technique à long terme.

Questions à poser à votre développeur ou prestataire cette semaine

• Qui relit le code écrit par l'IA avant sa fusion, et chaque modification a-t-elle une revue tracée ?
• Les tests sont-ils réellement exécutés sur le système, ou l'outil a-t-il simplement « affirmé » que le code fonctionne ?
• Quels droits ont les outils d'IA ? Peuvent-ils déployer, ou accéder à la vraie base de données ? (Voir ce qui s'est passé avec les agents de code qui ont exécuté la commande d'un attaquant.)
• Les données de test sont-elles synthétiques ? Le guide demande des données de test conformes aux règles de confidentialité, sans aucune donnée réelle ou sensible, ce qui compte pour les données personnelles de vos clients.
• Qui valide une version avant sa mise en ligne, et qui décide du retour arrière en cas de problème ?

Si vous n'obtenez pas de réponse claire à trois de ces cinq questions, le problème n'est pas l'outil d'IA mais la façon de travailler. Si vous choisissez un nouveau partenaire de développement, ajoutez ces questions à vos critères de choix d'une société de développement.

Le regard d'Origami

Nous utilisons des outils d'IA en conception, en programmation et en test, parce qu'ils font gagner un temps réel à nos clients. Mais nous traitons ce qu'ils écrivent exactement comme le décrit le guide de la SDAIA : comme un brouillon. Chaque modification passe par la revue d'un développeur, les tests sont réellement exécutés, les vraies données clients n'entrent jamais dans l'environnement de test, et c'est un humain qui décide du déploiement. La vitesse sans revue se paie plus tard en pannes et en failles. Si vous avez construit un prototype avec l'IA et voulez en faire un système fiable pour vos clients, parlons-en.