NON : le RAD génère une base fonctionnelle impressionnante sans écrire une ligne, mais toute application RÉELLE exige des règles métier, des contrôles, des enchaînements et des adaptations qui demandent de savoir programmer — le RAD accélère le développeur, il ne le remplace pas. Ce que le RAD fait VRAIMENT sans programmer : (1) Il génère des fenêtres de saisie et de consultation complètes, avec les champs liés aux rubriques. (2) Il produit le code standard de gestion des données : ajouter, modifier, supprimer, rechercher, parcourir. (3) Il crée des menus, des boutons, une navigation cohérente, parfois des états d'impression. (4) Résultat : une application qu'on peut lancer, dans laquelle on peut réellement saisir et consulter des données. C'est authentiquement impressionnant, surtout la première fois. Ce que le RAD ne peut PAS faire : (1) Vos RÈGLES MÉTIER. Le RAD ignore que vous accordez 5 % de remise au-delà de dix articles, qu'une commande ne peut pas être validée si le client a des impayés, qu'un stock ne doit jamais devenir négatif, ou qu'une facture suit un circuit de validation. Ces règles CONSTITUENT l'application — c'est même tout son intérêt métier — et elles s'écrivent en code. (2) Les CONTRÔLES de cohérence et les messages adaptés à vos utilisateurs. (3) Les ENCHAÎNEMENTS particuliers (depuis cette fiche, ouvrir tel écran avec tel contexte). (4) L'ERGONOMIE spécifique : le générique est correct, jamais optimal pour un métier donné. (5) Les traitements complexes : calculs, imports, exports, échanges avec d'autres systèmes, traitements par lot. (6) Les cas particuliers, qui font toujours la majorité du travail réel. Ce qu'il faut donc savoir faire : (1) Programmer en WLangage : variables, conditions, boucles, procédures — le minimum vital pour écrire vos règles. (2) CONCEVOIR une analyse correcte : c'est même le prérequis absolu, puisque le RAD en dépend entièrement. Cela demande de comprendre le modèle relationnel. (3) Manipuler les données (fonctions HFSQL, requêtes, SQL). (4) Comprendre le code généré pour pouvoir le modifier sans tout casser. (5) Tester et déboguer. La bonne façon de voir le RAD : (1) C'est un ACCÉLÉRATEUR : il fait en quelques minutes le travail répétitif et sans valeur ajoutée (le « plomberie » de la saisie et de la consultation), pour que vous consacriez votre temps à ce qui compte : le métier. (2) C'est un POINT DE DÉPART, pas un point d'arrivée. (3) C'est un OUTIL D'APPRENTISSAGE : lire le code généré enseigne beaucoup. (4) Attention à l'illusion : une démonstration RAD est spectaculaire, mais ne reflète pas la charge réelle d'un projet, où l'essentiel du travail porte sur les règles, les cas particuliers, l'ergonomie fine et les tests. En résumé : NON. Le RAD génère sans programmer une application réellement fonctionnelle — fenêtres de saisie et de consultation, tables, menus, code standard d'ajout/modification/suppression/recherche, parfois des états — ce qui est spectaculaire et fait gagner un temps considérable sur la partie répétitive. Mais une application d'entreprise ne se réduit pas à cela : ses RÈGLES MÉTIER (remises, contrôles de cohérence, stocks, circuits de validation), ses enchaînements, son ergonomie spécifique, ses traitements complexes (calculs, imports, échanges) et surtout ses innombrables CAS PARTICULIERS représentent l'essentiel du travail réel — et tout cela s'écrit en code. Il faut donc savoir programmer en WLangage, et d'abord savoir CONCEVOIR une analyse correcte, puisque le RAD en dépend entièrement. Voyez-le comme un accélérateur qui vous débarrasse de la plomberie pour vous laisser le temps du métier, comme un point de départ à personnaliser, et comme un excellent outil d'apprentissage — jamais comme un substitut au développeur.

Utilisez le RAD comme point de DÉPART, puis personnalisez : c'est le meilleur compromis entre gain de temps et maîtrise. Tout coder à la main gaspille du temps, mais générer sans jamais reprendre produit une application générique et impersonnelle. Les arguments POUR utiliser le RAD : (1) GAIN DE TEMPS massif sur la partie répétitive : chaque fichier de l'analyse demande une fenêtre de consultation et une fenêtre de saisie avec les mêmes mécanismes. Les écrire vingt fois à la main est un pur gaspillage. (2) COHÉRENCE : les écrans générés se ressemblent, respectent la charte et les standards de l'atelier — une homogénéité difficile à tenir manuellement. (3) Moins d'ERREURS : le code standard généré est éprouvé (liaisons, contrôles de base, navigation). (4) Base fonctionnelle immédiate : on peut montrer très vite quelque chose aux utilisateurs et recueillir leurs retours — précieux pour ajuster le besoin tôt. (5) Apprentissage : le code généré fait office d'exemple de bonnes pratiques. Les limites (pourquoi ne pas s'arrêter là) : (1) Ergonomie GÉNÉRIQUE : le RAD ne connaît ni vos priorités d'affichage, ni les habitudes de vos utilisateurs, ni les champs réellement importants. Une application 100 % RAD se voit immédiatement. (2) Aucune RÈGLE MÉTIER : c'est à vous de les ajouter. (3) Écrans parfois SURCHARGÉS : le RAD affiche généralement toutes les rubriques, alors que l'utilisateur n'en a besoin que de quelques-unes à l'écran principal. (4) Enchaînements standards, rarement ceux du métier. La démarche recommandée : (1) SOIGNEZ D'ABORD L'ANALYSE — c'est le prérequis : la qualité du RAD en découle directement. (2) GÉNÉREZ (RAD complet au démarrage, ou RAD par élément au fil de l'eau, souvent plus maniable). (3) TESTEZ l'application générée pour valider le modèle de données sur du concret : c'est un excellent moyen de détecter tôt une erreur d'analyse. (4) PERSONNALISEZ méthodiquement : retirez les champs inutiles de l'écran principal, réorganisez selon la logique d'usage, corrigez les libellés (les noms techniques ne parlent pas aux utilisateurs), soignez ancrages et ordre de tabulation. (5) AJOUTEZ vos RÈGLES MÉTIER et vos contrôles — le cœur de la valeur. (6) Faites VALIDER par les utilisateurs et itérez. (7) Pour les écrans très spécifiques (tableaux de bord, écrans de synthèse, assistants), construisez-les à la MAIN : le RAD n'y apporte rien. La règle pratique : (1) Écrans CRUD standards (saisie/consultation d'un fichier) → RAD puis personnalisation. (2) Écrans SPÉCIFIQUES (synthèses, tableaux de bord, processus métier) → à la main. (3) Ne considérez JAMAIS le résultat du RAD comme livrable en l'état. En résumé : utilisez le RAD comme POINT DE DÉPART puis personnalisez — c'est le meilleur équilibre. Le RAD fait gagner un temps considérable sur les écrans répétitifs de saisie et de consultation, garantit la cohérence visuelle et technique, réduit les erreurs et permet de montrer très vite une application fonctionnelle aux utilisateurs (donc d'ajuster le besoin tôt). Mais son résultat est GÉNÉRIQUE : écrans souvent surchargés (toutes les rubriques affichées), libellés techniques, ergonomie non adaptée aux habitudes métier et surtout AUCUNE règle métier. La démarche : soigner l'analyse d'abord (tout en découle), générer, tester pour valider le modèle sur du concret, puis personnaliser méthodiquement (retirer le superflu, réorganiser selon l'usage, corriger les libellés, régler ancrages et tabulation) et ajouter les règles métier — avant de faire valider par les utilisateurs. Réservez la construction manuelle aux écrans vraiment spécifiques (tableaux de bord, synthèses, assistants), où le RAD n'apporte rien. Et ne livrez jamais une application RAD en l'état.