← Derniers articles
💻 computer science

Test-Oriented Programming: rethinking coding for the GenAI era

Cet article propose le paradigme de la « Programmation Orientée Tests » (TOP), où les développeurs se concentrent uniquement sur la validation de tests générés à partir de spécifications en langage naturel, laissant aux modèles de langage le soin de produire le code de production, une approche dont la faisabilité est démontrée par un prototype prometteur malgré certains défis pour les projets réels.

Auteurs originaux : Jorge Melegati

Publié 2026-04-10
📖 4 min de lecture☕ Lecture pause café

Auteurs originaux : Jorge Melegati

Article original sous licence CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). Ceci est une explication générée par l'IA de l'article ci-dessous. Elle n'a pas été rédigée ni approuvée par les auteurs. Pour une précision technique, consultez l'article original. Lire la clause de non-responsabilité complète

Imaginez que vous êtes un architecte de maisons. Jusqu'à présent, pour construire une maison, vous deviez non seulement dessiner les plans, mais aussi superviser chaque pose de brique, chaque raccord de tuyauterie et chaque peinture. Même avec des assistants modernes (comme des robots qui vous aident à poser les briques plus vite), vous deviez toujours vérifier le travail manuel.

C'est là qu'intervient une nouvelle idée proposée par Jorge Melegati dans son article : la Programmation Orientée Tests (TOP).

Voici comment cela fonctionne, expliqué simplement avec des analogies :

1. Le changement de rôle : Du maçon à l'inspecteur

Dans le monde du développement logiciel actuel, les développeurs écrivent le code (les briques) et les tests (les vérifications). Avec l'Intelligence Artificielle (IA), on pourrait penser que l'IA écrit juste un peu plus vite.

Mais l'auteur propose un saut en avant : ne plus écrire les briques du tout.

  • L'ancienne méthode : Vous donnez des instructions à l'IA, elle écrit le code, et vous vérifiez si le code fonctionne.
  • La nouvelle méthode (TOP) : Vous ne donnez pas d'instructions sur comment construire la maison. Vous donnez une liste de règles strictes : "La porte doit s'ouvrir", "Le robinet ne doit pas fuir", "La lumière doit s'allumer quand on appuie".
  • Le résultat : L'IA construit la maison toute seule. Votre seul travail est de vérifier si les règles (les tests) sont bien écrites et si la maison les respecte. Si la maison ne respecte pas une règle, vous corrigez la règle, pas la maison.

2. L'outil "Oignon" : Le chef d'orchestre

Pour prouver que cela fonctionne, l'auteur a créé un petit outil appelé Oignon.
Imaginez Oignon comme un chef d'orchestre très zélé mais un peu brouillon :

  1. Vous lui donnez un menu (un fichier de configuration) avec ce que vous voulez faire (ex: "Gérer des livres bibliographiques").
  2. Oignon demande à l'IA de créer les règles du jeu (les tests).
  3. Vous, l'humain, vérifiez ces règles. "Oui, c'est bien ça que je veux".
  4. Oignon demande à l'IA de construire le logiciel pour respecter ces règles.
  5. Si le logiciel échoue aux tests, Oignon réessaie encore et encore jusqu'à ce que ça marche.

3. Ce qu'ils ont découvert (Les bonnes et les mauvaises nouvelles)

L'auteur a testé cet outil avec deux types d'IA différentes (comme comparer un robot très logique à un robot très bavard).

  • Le succès : C'est possible ! Ils ont réussi à créer un petit programme sans jamais écrire une seule ligne de code de production. Ils ont juste vérifié les règles.
  • Le problème 1 : Le volume de papier. Parfois, l'IA écrit des règles (des tests) si longues et compliquées que l'humain a du mal à les lire. C'est comme si le chef d'orchestre vous donnait une partition de 500 pages pour une chanson de 3 minutes. Il faut des outils pour résumer cela.
  • Le problème 2 : L'imprévisibilité. Si vous demandez la même chose deux fois à l'IA, elle peut donner deux réponses très différentes. Parfois, elle est très concise, parfois elle écrit des romans entiers. C'est difficile de savoir à quoi s'attendre.

En résumé

Cette recherche nous dit que l'avenir du code ne sera peut-être pas d'écrire des lignes de texte complexes, mais de définir clairement ce que le logiciel doit faire (les tests) et de laisser l'IA faire le travail sale de construction.

C'est comme passer de l'époque où l'on devait forger chaque épée à la main, à l'époque où l'on dessine simplement le plan de l'épée, et que l'usine la fabrique. Votre travail n'est plus de forger, mais de s'assurer que le plan est parfait.

Noyé(e) sous les articles dans votre domaine ?

Recevez des digests quotidiens des articles les plus récents correspondant à vos mots-clés de recherche — avec des résumés techniques, dans votre langue.

Essayer Digest →