En 1982, l'informaticien James Martin publiait un livre au titre étrangement actuel : Application Development Without Programmers, « le développement d'applications sans programmeurs ». Il en tirera en 1991 une méthode, le Rapid Application Development, ou RAD2. Trente-cinq ans plus tard, décrire une application en langage courant à un agent IA et la voir apparaître en quelques minutes est devenu banal. Martin Keen, pour IBM Technology, en tire une thèse simple : les quatre phases du RAD s'appliquent presque telles quelles au développement avec l'IA, à condition de ne pas oublier la moitié du plan de Martin que le vibe coding a laissée de côté1.
Les sections 1 à 4 suivent sa présentation, que je complète par des chiffres sourcés et par ce que j'ai vu en construisant Orthopy, un SaaS clinique écrit avec des agents et aujourd'hui en bêta fermée. Viennent ensuite les questions à poser avant de mettre en production une application générée par IA, puis mon analyse.
1. Le RAD, en une page
Le RAD privilégie la vitesse, l'itération et le retour des utilisateurs, là où presque tout le monde pratiquait alors le développement en cascade, avec sa longue planification initiale. Son hypothèse fondatrice : les utilisateurs ne savent pas vraiment ce qu'ils veulent tant qu'ils n'ont pas quelque chose sous les yeux à quoi réagir1.
La méthode tient en quatre phases, et chacune a aujourd'hui son équivalent avec un agent de code1 :
| Phase du RAD | Ce qu'elle fait | Avec un agent IA |
|---|---|---|
| 1. Planification des besoins | Volontairement légère : le problème, les utilisateurs concernés, les fonctionnalités voulues, les contraintes. Rien de plus. | Le prompt devient le cahier des charges. |
| 2. Conception avec les utilisateurs | Un prototype cliquable, mis devant de vrais utilisateurs pour attraper les mauvaises hypothèses tant qu'elles coûtent peu. Ce prototype n'est pas jeté : il grandit jusqu'à devenir le produit. | L'agent génère le prototype, les utilisateurs cliquent et commentent, l'agent régénère. |
| 3. Construction | Les fonctionnalités réelles, en cycles courts, avec tests et retours en continu plutôt qu'à la fin. | L'agent écrit le schéma de données, la logique métier, les notifications. |
| 4. Bascule | La mise en production, la migration des données et la formation des utilisateurs. | « Ça marche, quand est-ce que toute l'entreprise l'a ? » |
Le livre de Martin décrivait de petites équipes livrant des systèmes opérationnels dans des délais bornés d'environ 90 jours, à une époque où un projet logiciel d'entreprise courait souvent sur des années1.
Si le RAD n'a pas conquis les équipes de développement, c'est en grande partie parce que les générateurs de code de l'époque, les outils de génie logiciel assisté par ordinateur (CASE), ne savaient pas produire d'applications sophistiquées1. Ses critiques classiques pèsent aussi : une méthode taillée pour des équipes petites ou moyennes, qui exige beaucoup de temps de la part d'experts métier rares, et dont le côté « bricoler puis tester » peut faire l'impasse sur l'architecture3.
2. Le vibe coding, ou le RAD instantané
Le prototypage, autour duquel Martin avait bâti toute sa méthode, prend désormais quelques minutes. C'est pour cela, selon Keen, que les quatre phases s'appliquent si bien au développement avec l'IA1.
Son exemple est celui que tout le monde finit par construire : une application de validation de notes de frais. Quelqu'un du service financier décrit le problème en langage courant (les utilisateurs, les règles d'approbation), et c'est exactement la planification légère que demande la phase 1. L'agent génère une application qui fonctionne. Les utilisateurs la parcourent, trouvent l'écran de validation confus, renvoient leurs remarques ; l'agent régénère, et ainsi de suite. Pendant ce temps, il écrit déjà le schéma de données, la logique du circuit de validation et les notifications par e-mail : la construction est en cours1.
Sur le terrain. L'hypothèse fondatrice du RAD vaut aussi pour le développeur. Sur Orthopy, le réflexe initial de développeur rattachait les pièces justificatives (un audiogramme, un rapport de QI) au bilan en cours, ce qui forçait la logopède à re-téléverser le même fichier. La pratique clinique contredit ce modèle : ces documents sont réalisés par un praticien extérieur et restent valables un à deux ans, pour plusieurs bilans successifs. Le document appartient donc à l'enfant, déposé une fois et reconnu par chaque bilan qui le réclame6. C'est le besoin clinique qui a dicté le modèle de données, pas l'intuition du développeur.
3. Le piège de la bascule : la règle que personne n'a écrite
La démonstration plaît, et la question arrive : quand toute l'entreprise peut-elle l'avoir ? Dans le RAD classique, la réponse est connue : le prototype devient le produit. Faut-il pour autant déployer tel quel un code entièrement écrit par l'IA1 ?
En y regardant de plus près, le prompt n'a peut-être jamais précisé qu'un employé ne peut pas approuver ses propres notes de frais. L'agent n'a donc sans doute jamais écrit la règle de double validation : n'importe qui peut déclarer une dépense de 900 dollars et la valider lui-même1. En contrôle interne, c'est la séparation des tâches, l'une des règles les plus élémentaires qui soient. Elle manque parce que personne ne l'a demandée.
Ce type de défaut n'a rien d'exceptionnel. En juillet 2025, Veracode a testé plus de 100 modèles de langage sur Java, Python, C# et JavaScript : 45 % des échantillons de code ont échoué aux tests de sécurité et introduit des vulnérabilités du Top 10 de l'OWASP. Les modèles récents ou plus gros n'ont pas fait mieux : leur code fonctionne davantage, mais la sécurité, elle, stagne4.
Le point le plus fin de la présentation est ailleurs : les utilisateurs qui testent le prototype ne peuvent pas trouver cette faille, parce qu'on ne peut pas cliquer sur une règle qui n'existe pas1. Le retour utilisateur, cœur du RAD, attrape ce qui se voit ; il est aveugle à ce qui manque.
Sur le terrain. J'ai vécu exactement ce cas. Pendant le développement d'Orthopy, sur des données fictives, deux champs du copilote clinique partaient vers le modèle externe sans pseudonymisation, et ce pendant des mois. Une décision d'architecture affirmait pourtant que tous les champs de texte libre étaient couverts, et une vingtaine de tests d'anonymisation passaient au vert : ils vérifiaient le module avec sa propre logique. La réponse a été structurelle : une spécification de quatre garanties vérifiables, dont un test d'indiscernabilité qui exige que deux patients au contenu clinique identique produisent des envois identiques. Dès sa première exécution, ce test a révélé une autre fuite : la langue seconde de l'enfant partait en clair6. Aucun clic dans l'interface ne l'aurait montré.
4. La moitié oubliée du plan de Martin : la spécification
Les générateurs de code de l'époque n'avaient pas de fenêtre de discussion. Un analyste leur fournissait une spécification (le modèle de données, les règles métier) et l'outil en tirait du code de base. Le plan de Martin avait donc toujours deux moitiés : une description précise de ce que le système doit faire, et sa transformation en code qui fonctionne1.
Les agents IA ont fourni une excellente machine à produire du code. La moitié « description », elle, revient aujourd'hui sous le nom de développement piloté par la spécification (spec-driven development)1. GitHub l'a outillé en septembre 2025 avec Spec Kit : la spécification devient la source de vérité que les outils et les agents utilisent pour générer, tester et valider le code, en quatre étapes (spécifier, planifier, découper en tâches, implémenter). Le constat de départ est le même que celui de Keen : un prompt vague oblige le modèle à deviner une multitude d'exigences jamais formulées5.
Concrètement, ce que le prototype a appris est consigné par écrit : les règles métier, les critères d'acceptation, les exigences de sécurité. Un responsable sécurité qui lit cette spécification pose la question qu'aucun clic n'aurait fait naître : qu'est-ce qui m'empêche de valider mes propres dépenses ? Une fois la règle écrite, elle devient un test que le code généré doit passer. Le prototype reste conservé, mais ce qui part en production, c'est tout ce qu'il a appris, consigné dans la spécification1.
Sur le terrain. Sur Orthopy, aucun agent ne code sans une tâche rédigée d'avance : le pourquoi, les décisions déjà tranchées, les étapes de test dans l'ordre, les erreurs à éviter, ce qui est hors périmètre et les commandes de vérification de clôture. La spécification du pseudonymiseur, datée du 5 août 2026, va plus loin : chacune de ses quatre garanties nomme l'outil qui la vérifie6. C'est la spécification de Martin, avec une colonne de plus : la preuve.
5. Avant de mettre en production une application générée par IA
Le vibe coding a rendu la phase 2 presque gratuite. Les phases 3 et 4 ne le sont pas devenues. Pour un dirigeant de PME dont l'équipe a construit un outil avec un agent, voici les questions à poser avant la bascule.
| Question | Pourquoi elle compte | Signal d'alerte |
|---|---|---|
| « Quelles règles métier sont écrites quelque part, en dehors du prompt ? » | Une règle absente ne se voit pas en cliquant sur le prototype | « Tout est dans la conversation avec l'agent » |
| « Qui peut faire quoi ? Quelqu'un peut-il valider sa propre demande ? » | La séparation des tâches et les droits d'accès sont rarement demandés, donc rarement construits | Aucun rôle défini, tout le monde a tous les droits |
| « Quels tests prouvent ces règles ? » | Une règle de la spécification doit devenir un test que le code doit passer | Des tests qui vérifient seulement que l'écran s'affiche |
| « Qui a relu le code, et indépendamment de qui l'a écrit ? » | Un module qui se relit valide ses propres angles morts | « L'agent a vérifié son travail » |
| « Où partent les données, et qui peut les lire ? » | Données personnelles ou financières : RGPD, hébergement, fournisseur du modèle | Personne ne sait répondre |
| « Comment migre-t-on les données actuelles, et qui forme les utilisateurs ? » | C'est la phase 4 de Martin, pas un détail de fin de projet | « On verra au lancement » |
| « Qui maintient l'application dans six mois ? » | La spécification sert aussi de documentation pour la suite | « On redemandera à l'IA » |
6. Ce qui tient, et ce qui manque
Les quatre phases tiennent. Keen les résume ainsi : planifier léger, prototyper tôt, construire en cycles courts, et ne rien basculer en production avant vérification1. J'ajouterais que la bascule ne doit pas attendre la fin. Sur Orthopy, le code a été jugé prêt fin août et l'infrastructure a suivi ensuite ; le premier soir de la bêta, la logopède consultante n'a pas pu enregistrer un patient, à cause d'un champ vide refusé par une validation durcie. Le correctif était en production 48 minutes plus tard, mais c'est l'exploitation, pas les tests, qui a révélé ce bug : lancer l'exploitation plus tôt fait partie de ce que je referais autrement6.
Le manque : qui vérifie la spécification ? La présentation fait de la spécification le remède, et elle a raison. Mais une spécification peut être incomplète, elle aussi. Si le même agent écrit la spécification, le code et les tests, les trois partagent les mêmes angles morts. Dans l'exemple de Keen, ce n'est d'ailleurs pas la spécification qui trouve la faille : c'est un responsable sécurité, une autre personne, qui la lit. Tout repose sur l'indépendance du relecteur. Sur Orthopy, le dernier contrôle avant chaque envoi au modèle est écrit sans importer une seule ligne du module qu'il surveille, parce que deux implémentations qui se trompent de la même façon ne vérifient rien6.
L'autre manque : le goulot s'est déplacé. Le vibe coding accélère le prototype, pas la disponibilité des utilisateurs. La critique historique du RAD, qui exige beaucoup de temps de la part d'experts métier rares3, n'a pas disparu : elle est devenue la principale limite. Quand un prototype se régénère en minutes, c'est le temps de la personne qui le teste, et de celle qui écrit ce qu'il a appris, qui fixe le rythme.
Quant au titre de 1982, Application Development Without Programmers, la demande attend toujours sa double validation, conclut Keen : les programmeurs sont toujours là. Ils se sont simplement déplacés vers l'écriture de la spécification et la vérification du résultat1. C'est le même déplacement vers le jugement que décrit l'article sur le métier d'ingénieur IA.
En résumé
Le RAD de James Martin avait raison sur l'essentiel : on découvre ce qu'il faut construire en montrant quelque chose, et le prototype peut devenir le produit. Le vibe coding a rendu ce prototype instantané, mais il a aussi fait oublier la seconde moitié du plan de Martin : une description précise de ce que le système doit garantir. Une règle qui n'est pas écrite ne sera ni construite ni testée, et aucun utilisateur ne la verra manquer. La spécification comble ce trou, à condition d'être relue par quelqu'un d'autre que celui qui l'a écrite.
Si votre équipe a construit un outil avec l'IA et hésite à le mettre en production, c'est précisément l'objet de l'audit de code et de dette IA : retrouver les règles qui manquent, les tests qui ne testent rien et les secrets restés en clair, avec un rapport hiérarchisé par gravité. Pour une tâche concrète à automatiser proprement dès le départ, les Starters sont faits pour démarrer petit. Un premier échange se fait par la page de contact.
Sources
- IBM Technology — « What Is RAD? Why It Matters in the Age of AI Coding », Martin Keen (17 août 2026) : la présentation source des sections 1 à 4.
- James Martin — Application Development Without Programmers, Prentice-Hall, 1982 ; Rapid Application Development, Macmillan, 1991. Notice : « James Martin (author) », Wikipédia.
- Wikipédia — « Rapid application development » : phases de la méthode et critiques recensées.
- Veracode — « 2025 GenAI Code Security Report » (30 juil. 2025).
- GitHub — « Spec-driven development with AI: Get started with a new open source toolkit », Den Delimarsky (2 sept. 2025).
- Waelan — « Orthopy, du socle au déploiement : retour d'expérience » (13 sept. 2026).