Du vibe coding à l'UltraCoding : quatre pratiques pour un code vérifiable

Ce que recouvre vraiment le vibe coding

Le vibe coding, expression proposée par Andrej Karpathy en février 2025, décrit une pratique où l’on formule une intention en langage naturel, accepte largement le code généré et itère sur le résultat sans examiner chaque ligne [1].

• Karpathy situait cette pratique dans le registre des projets personnels et jetables.
• Simon Willison réserve le terme au cas où l’on ne lit pas le code produit, et distingue cette approche du développement assisté par IA avec compréhension et revue [2].
• Collins a consacré l’expression « mot de l’année » 2025, signe de sa diffusion culturelle plutôt que validation de sa pertinence en production [3].

Le choix de la méthode dépend donc de la durée de vie et du risque du logiciel, car la souplesse utile à un prototype devient une dette dès que le code traite des clients, de l’argent, des données sensibles ou une activité durable.

• Pour explorer : viser un apprentissage rapide et prévoir la suppression du prototype.
• Pour conserver : identifier un propriétaire, documenter les choix et installer les tests utiles.
• Pour produire : ajouter les contrôles de sécurité, d’exploitation et d’expérience adaptés aux conséquences d’une défaillance.

Ce que mesurent réellement les études disponibles

Les travaux disponibles invitent à vérifier le code généré, mais chacun porte sur un dispositif précis et aucun ne permet de calculer à lui seul la probabilité de défaut, le gain de productivité ou la stabilité future d’un projet particulier.

• Sécurité : dans le benchmark 2025 de Veracode, 45 % des échantillons générés ont échoué aux tests de sécurité ; cette proportion agrège plus de 100 modèles, 80 tâches et quatre langages, et ne représente pas un risque de vulnérabilité « par défaut » en production [4].
• Productivité : l’essai randomisé de METR a observé un ralentissement de 19 % chez 16 développeurs expérimentés réalisant 246 tâches dans des dépôts qu’ils connaissaient bien ; METR présente ce résultat comme un instantané des outils de début 2025 dans ce contexte [5].
• Livraison : DORA 2025 observe une association entre une adoption plus forte de l’IA, davantage de débit et davantage d’instabilité ; l’étude décrit un effet d’amplification des pratiques existantes, pas une causalité mécanique pour chaque équipe [6].

Ces résultats convergent vers une décision pratique : l’équipe doit mesurer le comportement de son propre système et conserver des preuves de contrôle au lieu de déduire sa qualité d’un benchmark, d’une démonstration convaincante ou du nom du modèle.

• Définir les risques et les critères d’acceptation avant la génération.
• Tester sur le code, l’architecture et l’environnement réellement livrés.
• Examiner les écarts, corriger puis conserver les résultats qui fondent la décision.
• Faire signer la livraison par une personne responsable lorsque l’enjeu le demande.

L’UltraCoding comme méthode de livraison

Nous appelons UltraCoding une organisation du développement assisté par agents dans laquelle la génération n’est qu’une étape et la livraison repose sur quatre pratiques coordonnées, traversées par des contrôles de sécurité, d’accessibilité et d’internationalisation.

• Orchestrer des rôles distincts lorsque le travail se décompose utilement.
• Contredire la première solution par une revue orientée défauts et hypothèses.
• Tester le comportement, les qualités transverses et l’interface rendue.
• Décider à partir de seuils définis et d’un arbitrage humain explicite.

Cette méthode vise une qualité vérifiable dans un périmètre donné, sans promettre un logiciel exempt de défauts ni confondre la validation par un agent avec une assurance indépendante.

• Les agents peuvent partager les mêmes angles morts, données d’entraînement ou erreurs de raisonnement.
• Les tests ne prouvent que les propriétés et scénarios effectivement couverts.
• L’assurance indépendante suppose une séparation suffisante des personnes, outils, intérêts ou environnements selon le risque.

Pratique 1 : orchestrer quand le travail se parallélise

Une architecture multi-agents est pertinente lorsque plusieurs pistes peuvent être explorées séparément, mais son intérêt doit être évalué sur la tâche visée plutôt que déduit des résultats d’un système de recherche [7].

• Un orchestrateur découpe le problème, distribue des mandats bornés et rassemble les résultats.
• Des spécialistes peuvent traiter en parallèle l’architecture, l’implémentation, les tests ou la documentation lorsque leurs dépendances restent maîtrisables.
• Les interfaces, critères de fin et mécanismes de résolution des conflits comptent autant que le nombre d’agents.

Le retour d’expérience d’Anthropic fournit un repère utile mais étroit : son système multi-agents a dépassé Claude Opus 4 seul de 90,2 % sur une évaluation interne de recherche et a utilisé environ 15 fois les jetons d’une conversation [7].

• Le gain concerne des recherches larges comportant des directions indépendantes.
• Les 15× décrivent cette architecture et cette comparaison, pas l’économie universelle des workflows de code.
• Anthropic indique lui-même que de nombreuses tâches de programmation ont moins de parallélisme et davantage de dépendances.
• Une décision de déploiement exige donc un test local de la qualité, du délai, du coût et du taux de reprise.

Pratique 2 : organiser une contradiction traçable

La revue contradictoire demande à un second agent de chercher les erreurs, hypothèses fragiles et cas limites du premier résultat, puis rattache chaque critique à une preuve exécutable ou à une décision humaine [8][9][10].

• Une compilation, un test ou un analyseur statique peut confirmer certains défauts de manière reproductible.
• Un agent critique peut proposer des scénarios oubliés, sonder les autorisations et rechercher des fuites ou injections.
• Le générateur répond aux constats, tandis qu’un responsable tranche les désaccords et accepte le risque résiduel.

Cette séparation améliore la détection sans créer automatiquement une assurance indépendante, car deux agents peuvent partager un modèle, un fournisseur, un contexte ou un harnais qui reproduisent les mêmes biais.

• Pour un changement courant : combiner critique agentique, tests automatiques et revue de code proportionnée.
• Pour un composant sensible : ajouter des outils de sécurité spécialisés et un examinateur suffisamment séparé du producteur.
• Pour une obligation réglementaire ou contractuelle : faire déterminer les contrôles et l’indépendance requis par les textes et le contexte applicables.

Pratique 3 : tester le logiciel sur trois couches

Une stratégie de test utile couvre séparément le comportement attendu, les qualités transverses et l’interface rendue, afin qu’un succès sur une couche ne masque pas les défauts que seule une autre peut révéler.

• Comportement : tests unitaires, d’intégration et de bout en bout sur les parcours et erreurs prévus.
• Qualités transverses : analyse de sécurité, détection de secrets, dépendances, autorisations, journalisation, internationalisation et critères WCAG applicables [12].
• Interface : captures sur les états et tailles d’écran critiques, comparaison de régression et inspection visuelle assistée.

Les modèles vision-langage peuvent repérer et décrire des anomalies visibles, tandis que l’évaluation d’une expérience reste une activité humaine nourrie par la recherche utilisateur, les tests d’usage et les contraintes métier [11].

• L’IA visuelle pré-classe des captures, suggère des problèmes et accélère la documentation.
• Les tests techniques confirment les états reproductibles, les interactions et les critères d’accessibilité automatisables.
• Des personnes représentatives révèlent les incompréhensions, attentes et compromis qui ne se lisent pas dans une image.
• Le responsable design décide si l’expérience convient au public et à la situation réels.

Pratique 4 : relier chaque livraison à des seuils explicites

La boucle de livraison répète génération, contradiction, test et correction jusqu’à satisfaire des critères convenus, puis soumet les éléments non automatisables et le risque résiduel à la personne qui possède la décision.

• Définir les tests obligatoires, leur environnement et les tolérances avant le travail.
• Bloquer la livraison sur les échecs critiques convenus, par exemple une régression fonctionnelle ou une vulnérabilité critique détectée.
• Documenter les dérogations, leur durée, leur propriétaire et le plan de correction.
• Réévaluer les seuils avec les incidents, les retours d’usage et l’évolution du produit.

Un seuil rend la décision observable et répétable dans son périmètre, mais il ne garantit ni l’absence absolue de vulnérabilité ni une conformité globale que seuls des contrôles adaptés à chaque système, acteur et obligation peuvent étayer.

• « Aucun défaut critique détecté par les outils définis » est un critère vérifiable.
• « Le logiciel est sûr » dépasse ce que ce résultat permet d’affirmer.
• La mise en production reste une décision de risque, avec supervision, observabilité et capacité de retour arrière.

Dimensionner l’effort selon le risque et l’économie réelle

Le niveau de contrôle doit croître avec la durée de vie, l’exposition et le coût d’une défaillance, tandis que son économie se calcule sur les mesures locales plutôt que sur le multiplicateur de jetons d’une autre application.

• Un script jetable peut se contenter d’une vérification courte et d’un périmètre fermé.
• Un service client, un flux financier ou un traitement de données personnelles justifie davantage de tests, de séparation et de traçabilité.
• Les métriques à suivre comprennent le coût complet, le délai, les reprises, les défauts échappés et les incidents évités sans double comptage.

L’hébergement interne peut répondre à des contraintes de contrôle ou de localisation, mais il ne transforme pas gratuitement le calcul en avantage : matériel, énergie, disponibilité, exploitation, sécurité, mises à jour et compétences entrent tous dans le coût total.

• Comparer des modèles et niveaux de qualité équivalents sur une charge représentative.
• Intégrer l’utilisation réelle, les périodes creuses, la redondance et le coût du personnel.
• Vérifier les conditions contractuelles et les flux de données avant de qualifier une solution de souveraine.
• Choisir entre API, hébergement dédié et modèle hybride avec une analyse de coût total documentée.

Les questions qu’un dirigeant peut exiger

Un dirigeant n’a pas besoin de choisir chaque outil pour instaurer cette discipline, mais il doit demander qui produit, qui contrôle, quelles preuves déclenchent la livraison et qui répond du risque restant.

• Qui relit le code généré, avec quel degré de séparation et quel pouvoir de blocage ?
• Quels tests couvrent le comportement, la sécurité, l’accessibilité, l’internationalisation et les interfaces ?
• Quels seuils empêchent une mise en production, et comment les dérogations sont-elles suivies ?
• Quelles mesures comparent le coût total, la vitesse et la qualité après livraison ?

Le développeur conserve alors un rôle central : il formule les contraintes, choisit les preuves pertinentes, arbitre les cas que l’automatisation ne tranche pas et assume la décision de livraison.

• L’agent produit et explore à grande vitesse.
• Les outils apportent des observations limitées à leur couverture.
• Les spécialistes interprètent les résultats dans le contexte technique et métier.
• Le responsable humain accepte, reporte ou refuse la livraison.

Passer de la génération à la preuve

L’UltraCoding organise une idée simple : plus la génération de code devient facile, plus la valeur se déplace vers des critères explicites, des contrôles complémentaires et une responsabilité humaine capable de défendre la livraison.

• Utiliser le vibe coding pour explorer dans un périmètre où l’échec reste peu coûteux.
• Installer les quatre pratiques dès que le logiciel doit durer ou que son défaut a des conséquences.
• Adapter la profondeur des contrôles aux risques observés, sans transformer un benchmark en promesse individuelle.

L’audit de maturité IA Junyr est un échange vidéo gratuit et sans engagement de 30 minutes qui donne une première position exploitable, suivie d’une synthèse d’une page.

• Votre position sur l’échelle de maturité.
• Le principal frein à traiter.
• Le premier projet raisonnable à engager.
• Une synthèse d’une page après l’échange.

Réserver l’audit de 30 minutes.

---

Sources

[1] Andrej Karpathy, publication à l’origine de l’expression vibe coding, 2 février 2025. https://x.com/karpathy/status/1886192184808149383

[2] Simon Willison, « Not all AI-assisted programming is vibe coding (but vibe coding rocks) », 19 mars 2025. https://simonwillison.net/2025/Mar/19/vibe-coding/

[3] Collins Dictionary, « Collins’ Word of the Year 2025: AI meets authenticity as society shifts », 6 novembre 2025. https://blog.collinsdictionary.com/language-lovers/collins-word-of-the-year-2025-ai-meets-authenticity-as-society-shifts/

[4] Veracode, 2025 GenAI Code Security Report. https://www.veracode.com/wp-content/uploads/2025_GenAI_Code_Security_Report_Final.pdf

[5] METR, « Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity », 10 juillet 2025. https://metr.org/blog/2025-07-10-early-2025-ai-experienced-os-dev-study/

[6] DORA, State of AI-assisted Software Development 2025. https://dora.dev/research/2025/dora-report/

[7] Anthropic, « How we built our multi-agent research system », 13 juin 2025. https://www.anthropic.com/engineering/multi-agent-research-system

[8] OpenAI, « Finding GPT-4’s mistakes with GPT-4 », 27 juin 2024. https://openai.com/index/finding-gpt4s-mistakes-with-gpt-4/

[9] Madaan et al., Self-Refine: Iterative Refinement with Self-Feedback, 2023. https://arxiv.org/abs/2303.17651

[10] Shinn et al., Reflexion: Language Agents with Verbal Reinforcement Learning, 2023. https://arxiv.org/abs/2303.11366

[11] Lu et al., UXAgent: An LLM Agent-Based Usability Testing Framework for Web Design, CHI 2025. https://arxiv.org/abs/2502.12561

[12] W3C, Web Content Accessibility Guidelines (WCAG) 2.2. https://www.w3.org/TR/WCAG22/