Un générateur d’interface d’administration fait gagner trois semaines au démarrage et peut coûter six mois le jour où une règle métier ne rentre pas dans son modèle. Ce n’est pas un procès en médiocrité : ces outils sont excellents dans leur domaine, et refuser de les utiliser par principe est aussi coûteux que les utiliser partout. Le problème est qu’ils sont choisis pour la mauvaise raison — la rapidité de la première démonstration — alors que le seul critère qui compte se mesure avant de coder : la part de vos écrans qui relèvent du CRUD pur, c’est-à-dire de la création, lecture, modification et suppression d’enregistrements, sans logique métier au milieu.
Cet article donne la méthode pour calculer cette part sur votre propre besoin, décrit les quatre situations où un générateur casse, et chiffre ce que coûte la sortie. Il s’appuie sur un relevé de banc sans ambiguïté : trois manières d’afficher la même liste de 5 000 lignes, qui transfèrent le même poids à quelques kilo-octets près — 643, 708 et 709 Ko — et donnent des expériences radicalement différentes, de 1 668 ms de premier affichage à une page instantanée. Ce relevé explique pourquoi la volumétrie est le mur que les générateurs rencontrent le plus souvent.
Les trois familles de solutions
Le marché propose trois approches, et la confusion entre elles est la première source de mauvais choix. Les générateurs partent de votre modèle de données et produisent les écrans : vous déclarez une ressource, vous obtenez une liste, un formulaire, des filtres, une recherche, la gestion des droits de base. Les bibliothèques de composants ne génèrent rien : elles fournissent les briques visuelles — tableaux, formulaires, sélecteurs — que vous assemblez, avec vos règles, dans vos écrans. Le sur-mesure complet écrit les écrans un par un, au-dessus du cadre applicatif.
| Famille | Coût de démarrage | Ce qu’elle impose | Coût d’un écran hors norme |
|---|---|---|---|
| Générateur | Très faible : quelques jours pour trente écrans | Son modèle de données, son modèle de droits, sa manière d’afficher les listes | Élevé : il faut soit le contourner, soit sortir de l’outil pour cet écran |
| Bibliothèque de composants | Moyen : les briques sont fournies, l’assemblage est à votre charge | Une grammaire visuelle, rien sur vos données ni vos règles | Faible : l’écran hors norme s’écrit comme les autres |
| Sur-mesure complet | Élevé : chaque écran est écrit | Rien, hormis vos propres conventions | Faible, mais chaque écran ordinaire coûte aussi plein tarif |
La lecture du tableau donne déjà la stratégie gagnante dans la plupart des projets, et elle n’est ni tout l’un ni tout l’autre : générateur pour les écrans ordinaires, sur-mesure pour les écrans métier, à condition d’avoir décidé lesquels sont lesquels avant de commencer. Ce qui échoue, c’est de découvrir en cours de route qu’un écran essentiel est hors modèle — parce qu’à ce stade, le générateur structure déjà l’authentification, la navigation et les droits de toute l’application.
Le test de la part de CRUD pur
Voici la mesure à faire avant de choisir, et elle prend une demi-journée. Listez tous les écrans de la future application — une ligne par écran, sans exception, y compris les écrans d’export et de paramétrage. Puis classez chaque ligne dans l’une des trois catégories suivantes, sans en inventer une quatrième.
CRUD pur : l’écran affiche, crée, modifie ou supprime des enregistrements d’une table, avec des filtres et une recherche, et aucune règle métier ne s’exécute au milieu. Une liste de fournisseurs, une fiche de produit, un catalogue de références. CRUD avec règle : l’écran ressemble à du CRUD mais une règle s’applique — un champ dépend d’un autre, une modification déclenche un calcul ou une notification, certaines lignes sont invisibles pour certains utilisateurs. Écran métier : l’écran n’est pas une table — un tableau de bord, un plan de charge, un rapprochement entre deux sources, un assistant en plusieurs étapes.
| Part de CRUD pur | Orientation | Précaution |
|---|---|---|
| Plus de 80 % | Générateur, sans hésiter | Vérifier que les écrans métier restants peuvent vivre à côté, hors de l’outil |
| Entre 50 et 80 % | Générateur pour le CRUD, écrans métier écrits à part | Décider dès le premier jour où passe la frontière, et la documenter |
| Entre 30 et 50 % | Bibliothèque de composants | Le générateur ferait gagner peu et contraindrait beaucoup |
| Moins de 30 % | Sur-mesure complet | Le gain d’un générateur serait marginal et son modèle, un obstacle permanent |
Un avertissement sur le décompte : les écrans métier sont systématiquement sous-représentés dans les listes faites en début de projet, parce qu’ils sont plus difficiles à imaginer que les listes ordinaires. Une part de CRUD pur mesurée à 85 % descend souvent à 60 % une fois le cadrage terminé. Prenez une marge, et faites le décompte avec les utilisateurs finaux plutôt qu’avec le seul commanditaire — ce sont eux qui savent quels écrans ils ouvrent vingt fois par jour.
Ce qu’un générateur fait très bien
Il faut lui rendre justice, parce que le gain est réel et mesurable. Sur une trentaine de ressources ordinaires, un générateur produit en quelques jours ce qui demanderait plusieurs semaines à écrire : listes paginées, tri, filtres, recherche, formulaires validés, messages d’erreur cohérents, actions de masse, exports, journalisation des modifications. Il apporte aussi une homogénéité que le sur-mesure obtient rarement — trente écrans écrits à la main par trois développeurs ne se ressemblent pas, trente écrans générés si.
Il y a un bénéfice moins évident et plus durable : le générateur impose une discipline de modélisation. Pour qu’un écran se génère proprement, le modèle de données doit être propre — relations déclarées, contraintes en base, nommage cohérent. Les projets qui commencent par un générateur ont souvent un meilleur schéma que ceux qui commencent par des écrans, parce que le raccourci sale y est plus difficile.
La conclusion pratique est donc nuancée : pour un outil interne dont l’essentiel est de saisir et consulter des enregistrements — un référentiel, un annuaire, une base documentaire — le générateur est le bon choix, et le débattre est une perte de temps. Le sujet de cet article commence là où cette description cesse d’être exacte.
Les quatre cas où un générateur casse
Premier cas : les droits par ligne. Un générateur gère nativement les droits par écran — qui peut voir la liste des commandes, qui peut la modifier. Il gère beaucoup moins bien les droits par ligne : ce commercial voit les commandes de ses clients, son responsable voit celles de sa région, la comptabilité voit toutes les commandes mais aucun commentaire commercial. Ce type de règle traverse toutes les requêtes de l’application et doit être appliqué au niveau de l’accès aux données, pas à celui de l’affichage. C’est exactement le poste que nous identifions comme décisif dans le chiffrage d’un intranet sur mesure, et il ne se rattrape pas après coup : le rétrofiter sur trente écrans générés coûte plus cher que de l’avoir conçu d’emblée.
Deuxième cas : les actions métier composées. « Valider un dossier » n’est pas une modification de champ : c’est vérifier des conditions, écrire dans trois tables, envoyer une notification, produire un document et journaliser l’opération, le tout dans une transaction qui doit tout annuler en cas d’échec. Un générateur sait attacher une action à une ressource ; il ne sait pas structurer une opération métier transactionnelle, et le code qu’on y glisse finit par vivre dans un endroit prévu pour de la présentation.
Troisième cas : les écrans de synthèse. Un tableau de bord ne dérive d’aucune table : il agrège plusieurs sources, sur des périodes, avec des règles de calcul qui appartiennent au métier. Le générateur n’a rien à générer — et l’écrire à l’intérieur de l’outil revient à écrire une application dans une application.
Quatrième cas : la volumétrie. C’est le plus mécanique, et le plus facile à mesurer. La section suivante lui est consacrée.
La volumétrie : ce que les générateurs ne fenêtrent pas
Un générateur pagine, mais pagine parfois large — et surtout, il affiche tout ce qu’on lui demande d’afficher. Le relevé de banc suivant compare trois manières de présenter la même liste de 5 000 lignes, sur la même machine et avec le même jeu de données.
| Technique | Premier affichage | Éléments dans la page | Tâche bloquante | Poids transféré |
|---|---|---|---|---|
| 5 000 lignes dans le HTML | 1 668 ms | 35 021 | — | 643 Ko |
| Lignes construites par script | 92 ms | — | 2 478 ms | 708 Ko |
| Liste fenêtrée | — | 219 | Aucune | 709 Ko |
Le fait marquant est celui que montre le graphique : les trois techniques transfèrent le même poids, à 66 Ko près. Le réseau n’explique donc rien. Ce qui explique tout, c’est ce que le navigateur doit construire : 35 021 éléments dans le premier cas, 219 dans le dernier. Dans le premier, la page met 1 668 ms à s’afficher parce que le navigateur assemble une structure énorme avant de montrer quoi que ce soit. Dans le deuxième, la page apparaît en 92 ms — excellent chiffre — puis une tâche bloquante de 2 478 ms gèle l’interface pendant que le script construit les lignes : l’utilisateur voit la page, clique, et rien ne répond. Dans le troisième, seules les lignes visibles existent, et il n’y a ni attente ni gel.
Ce relevé a une conséquence directe sur le choix d’un générateur : demandez comment il affiche une liste de plusieurs milliers de lignes, et vérifiez-le sur vos propres volumes, pas sur une démonstration à cinquante enregistrements. Beaucoup de générateurs paginent correctement les listes principales mais rendent des sélecteurs de relation qui chargent l’intégralité d’une table — le champ « client » d’un formulaire qui embarque vos 12 000 clients est le cas typique, et il produit exactement le deuxième scénario du tableau. C’est aussi ce que montrent, dans un autre contexte, les deux mesures qui décident d’un intranet : le facteur limitant d’un outil interne est presque toujours le nombre d’éléments manipulés, jamais le débit disponible.
La question des droits, encore
Revenons-y, parce que c’est le poste qui décide du coût total et que la moitié des projets le tranche par défaut. Deux modèles existent, et ils n’ont ni le même prix ni la même trajectoire.
| Modèle | Où la règle s’applique | Coût initial | Coût du changement de modèle |
|---|---|---|---|
| Droit par écran | À l’entrée de l’écran : l’utilisateur y accède ou non | Faible, souvent natif dans un générateur | Sans objet |
| Droit par ligne | Dans chaque requête de lecture et d’écriture, sans exception | Élevé, mais conçu une fois pour toute l’application | Très élevé : chaque écran existant doit être repris et retesté |
La règle à retenir est celle-ci : le modèle de droits se décide avant le premier écran, jamais après le trentième. Si un seul cas d’usage exige un droit par ligne — « chaque commercial ne voit que ses clients » suffit —, alors toute l’application doit être construite sur ce modèle dès le départ, y compris les écrans qui n’en ont pas besoin. Un modèle de droits mixte, où certains écrans filtrent par ligne et d’autres non, est la garantie d’une fuite de données : il suffit d’un export oublié.
Le coût de sortie
Sortir d’un générateur ne consiste pas à réécrire des écrans : cela, c’est le travail visible et le plus simple à chiffrer. Le coût réel est dans ce que l’outil fournissait sans qu’on y pense — l’authentification et les sessions, la navigation, le système de droits, la validation des formulaires et ses messages, la journalisation des modifications, les exports, la gestion des fichiers joints. Chacune de ces briques doit être reconstruite ou remplacée avant que le premier écran réécrit ne fonctionne.
D’où une recommandation concrète, à appliquer dès le premier jour même quand on choisit le générateur : isolez la logique métier hors de l’outil. Les règles — validation d’un dossier, calcul d’un tarif, contrôle de cohérence — vivent dans des classes de service appelées par les écrans, jamais dans le code de configuration du générateur. Le jour de la sortie, la logique est intacte et seule la présentation est à refaire ; la sortie devient un chantier de semaines au lieu d’un chantier de mois. Cette précaution ne coûte presque rien au départ, et c’est la meilleure assurance qu’on puisse souscrire sur ce type de projet. Elle sert aussi dans un autre cas de figure fréquent : quand il faut connecter un site et un ERP, la logique isolée se réutilise telle quelle côté intégration, alors qu’une logique noyée dans des écrans est à réécrire.
Le cas de l’outil qui a déjà grossi
La situation la plus fréquente n’est pas un choix à faire mais un constat à traiter : l’outil existe, il a été monté avec un générateur il y a deux ans, et il craque. Le réflexe est d’envisager une réécriture complète ; c’est presque toujours le plus mauvais scénario, parce qu’il remet en jeu ce qui fonctionne pour corriger ce qui ne fonctionne pas.
La méthode que nous appliquons tient en trois temps. D’abord, identifier les écrans qui posent problème — ils sont rarement plus de cinq sur trente, et ce sont toujours les mêmes catégories : un écran de synthèse, une ou deux actions métier devenues complexes, une liste devenue trop longue. Ensuite, sortir ces écrans-là du générateur en les écrivant à part, tout en gardant l’authentification, la navigation et le reste des écrans dans l’outil. Enfin, extraire la logique métier de ces écrans vers des services, pour que le prochain déplacement ne coûte rien.
Cette cohabitation a mauvaise presse et pourtant elle tient très bien, à une condition non négociable : le modèle de droits doit être commun aux deux mondes. Deux systèmes de droits parallèles, l’un dans le générateur et l’autre dans les écrans écrits à la main, produisent tôt ou tard une divergence — et une divergence de droits est une fuite de données. Si le générateur ne permet pas de partager son modèle de droits avec du code externe, alors la cohabitation n’est pas possible et l’arbitrage redevient binaire.
Le tableau de décision
| Situation | Orientation | Point de vigilance |
|---|---|---|
| Référentiel ou annuaire, droits par écran, volumes modestes | Générateur | Vérifier le comportement des sélecteurs de relation sur vos volumes |
| Outil de saisie avec deux ou trois écrans de synthèse | Générateur + écrans métier écrits à part | Fixer la frontière et la documenter dès le cadrage |
| Un seul cas de droit par ligne, même marginal | Concevoir le modèle de droits d’abord, quel que soit l’outil | Aucun modèle mixte : la fuite passe par l’export oublié |
| Actions métier transactionnelles nombreuses | Bibliothèque de composants ou sur-mesure | La logique reste dans des services, hors des écrans |
| Listes de plusieurs milliers de lignes consultées quotidiennement | Fenêtrage obligatoire, quelle que soit la famille | Mesurer éléments dans la page et tâches bloquantes, pas le poids |
| Moins de 30 % de CRUD pur au décompte | Sur-mesure complet | Le décompte sous-estime toujours les écrans métier : prendre une marge |
Ce qu’il faut retenir
Le choix d’une interface d’administration ne se joue pas sur la rapidité de la première démonstration mais sur un décompte à faire avant de coder : la part de vos écrans qui relèvent du CRUD pur. Au-delà de 80 %, le générateur s’impose ; entre 50 et 80 %, il couvre le CRUD et les écrans métier s’écrivent à côté ; en dessous de 30 %, son modèle serait un obstacle permanent. Et ce décompte sous-estime toujours les écrans métier — prenez une marge, et faites-le avec ceux qui utiliseront l’outil tous les jours.
Quatre situations font céder un générateur : les droits par ligne, les actions métier transactionnelles, les écrans de synthèse et la volumétrie. Le banc chiffre la dernière sans appel : la même liste de 5 000 lignes transfère 643, 708 et 709 Ko selon la technique — donc le réseau n’explique rien — mais construit 35 021 éléments et met 1 668 ms à s’afficher dans un cas, gèle l’interface 2 478 ms après un affichage en 92 ms dans un autre, et se contente de 219 éléments sans aucune tâche longue quand elle est fenêtrée.
Deux décisions se prennent au premier jour et ne se rattrapent pas ensuite : le modèle de droits, qui doit porter sur les lignes dès qu’un seul cas d’usage l’exige, et l’isolement de la logique métier hors de l’outil. La seconde coûte presque rien à mettre en place et transforme une éventuelle sortie du générateur en chantier de semaines plutôt qu’en réécriture. C’est la meilleure assurance disponible sur ce type de projet — et la seule qu’on ne peut pas souscrire après l’incident.
