Créez un COMPOSANT quand le module doit être partagé entre PLUSIEURS PROJETS et qu'il forme un ensemble cohérent (avec fenêtres, états, classes) ; une collection de procédures suffit largement pour organiser le code À L'INTÉRIEUR d'un même projet. La collection de procédures : (1) Rôle : regrouper par thème des procédures d'un même projet (utilitaires de dates, calculs commerciaux, fonctions d'export). (2) Avantages : très simple, immédiate, aucune gestion de version, aucun packaging. (3) Suffisante quand : vous structurez un projet, vous factorisez du code réutilisé à plusieurs endroits DANS ce projet, vous n'avez besoin de partager que des traitements (pas d'écrans). (4) Limite : elle appartient au projet. Pour l'utiliser ailleurs, on la recopie — et on retombe dans la duplication (deux copies qui divergent). Le composant : (1) Rôle : empaqueter un ENSEMBLE cohérent (fenêtres, états, classes, procédures, ressources) pour l'utiliser dans D'AUTRES projets. (2) À créer quand : le module a une identité fonctionnelle claire (« gestion des utilisateurs et des droits », « module de facturation », « connecteur vers un service externe »), il comporte plus que des procédures (des écrans notamment), et il servira à PLUSIEURS applications. (3) Avantage décisif : correction CENTRALISÉE. Vous corrigez un défaut dans le composant, et tous les projets qui l'intègrent en bénéficient — au lieu de corriger dans cinq copies. (4) Encapsulation : le composant expose une interface et cache son fonctionnement interne, ce qui protège les projets utilisateurs des détails d'implémentation. (5) Coût : il faut concevoir l'interface, documenter, versionner, tester — un vrai travail d'ingénierie. Comment décider : (1) « Ce code sert-il dans PLUSIEURS projets ? » Si non → collection de procédures. Si oui → envisagez un composant. (2) « Est-ce plus que des procédures ? » (fenêtres, états, classes) → composant. (3) « Est-ce un ensemble fonctionnel identifiable ? » → composant. (4) « Est-ce stable ou encore en pleine évolution ? » Un module qui change tous les jours n'est pas mûr pour être empaqueté : attendez la stabilisation. (5) Dans le doute, commencez par bien structurer en collections ; vous extrairez un composant le jour où le besoin de partage apparaît réellement. Ne créez pas un composant « au cas où ». Les bonnes pratiques du composant : (1) Interface CLAIRE et STABLE : c'est le point crucial. Ce que le composant expose doit être pensé et ne pas changer à chaque version, sinon tous les projets utilisateurs doivent être repris. (2) DOCUMENTATION : sans documentation, un composant est inutilisable par un tiers (et par vous-même dans six mois). (3) VERSIONS : sachez quel projet utilise quelle version, et gérez la compatibilité. C'est la principale difficulté pratique. (4) TESTS : un composant défectueux contamine tous les projets qui l'utilisent — d'où l'importance des tests automatiques. (5) Périmètre bien défini : un composant qui fait tout ne se réutilise pas. En résumé : utilisez une COLLECTION DE PROCÉDURES pour organiser le code à l'intérieur d'un projet — c'est simple, immédiat, sans gestion de version, et cela couvre l'essentiel du besoin de structuration. Passez au COMPOSANT lorsque trois conditions se réunissent : le module doit servir dans PLUSIEURS projets, il constitue un ensemble fonctionnel identifiable (« gestion des utilisateurs », « module de facturation », « connecteur externe ») et il contient plus que des procédures (fenêtres, états, classes). L'avantage décisif du composant est la correction CENTRALISÉE : un défaut corrigé une fois profite à toutes les applications, là où des copies dupliquées divergent inexorablement. Mais ce bénéfice a un coût d'ingénierie réel : concevoir une INTERFACE claire et surtout STABLE (si elle change à chaque version, tous les projets utilisateurs doivent être repris), DOCUMENTER, VERSIONNER en suivant qui utilise quoi, et TESTER rigoureusement — un composant défectueux contamine toutes les applications qui l'intègrent. Enfin, n'empaquetez pas trop tôt : un module encore instable n'est pas mûr pour devenir un composant. Structurez d'abord en collections, extrayez un composant le jour où le besoin de partage est avéré.

En combinant la CHARTE GRAPHIQUE (styles globaux appliqués à tous les champs), les MODÈLES de fenêtres (présentation commune héritée) et les FENÊTRES INTERNES (blocs réutilisés) — trois niveaux qui centralisent l'apparence au lieu de la disperser dans chaque écran. Niveau 1 — la CHARTE GRAPHIQUE : (1) Choisie à la création du projet, elle applique automatiquement des STYLES cohérents à tous les champs déposés (couleurs, polices, apparence des boutons, des tables, des saisies). (2) Bénéfice : cohérence immédiate sans effort, et modification centralisée — changer un style dans la charte se répercute sur toute l'application. (3) Règle : ne stylisez pas les champs un par un. Si un ajustement est nécessaire, modifiez le STYLE, pas le champ individuel. Niveau 2 — les MODÈLES DE FENÊTRES : (1) Un modèle définit la STRUCTURE commune : bandeau de titre, logo, boutons standards (Valider, Annuler, Fermer), zones fixes, disposition générale. (2) Les fenêtres qui en héritent reprennent tout cela AUTOMATIQUEMENT. (3) Bénéfice majeur : une modification du modèle (déplacer un bouton, changer le bandeau, ajouter un élément commun) se répercute sur TOUTES les fenêtres concernées. Sans modèle, il faudrait rouvrir cinquante fenêtres une par une — un travail que personne ne fait correctement. (4) Prévoyez éventuellement plusieurs modèles selon les types d'écrans (fiche de saisie, écran de consultation avec table, écran d'assistant). Niveau 3 — les FENÊTRES INTERNES et SUPERCHAMPS : (1) Pour un BLOC fonctionnel répété : une saisie d'adresse, un sélecteur de client avec recherche, un bandeau de filtres. (2) Écrit une fois avec son comportement, inséré partout où il est nécessaire. (3) Bénéfice : cohérence ET absence de duplication de code — une correction bénéficie à tous les écrans qui l'utilisent. Les autres leviers : (1) CONVENTIONS d'équipe : positions standard des boutons, ordre des actions, formulation des libellés et des messages. Écrivez-les et faites-les appliquer. (2) Libellés et terminologie cohérents : ne dites pas « Client » ici et « Tiers » là. La cohérence du VOCABULAIRE compte autant que celle des couleurs. (3) Comportements homogènes : la touche Entrée valide toujours, Échap annule toujours, les messages d'erreur ont le même ton et la même forme. (4) RELECTURE régulière : parcourez l'application avec un œil neuf pour repérer les écarts. Pourquoi c'est important : (1) PROFESSIONNALISME perçu : une application cohérente inspire confiance ; une application hétérogène donne l'impression d'un assemblage bâclé, même si le code est excellent. (2) APPRENTISSAGE : l'utilisateur qui apprend un écran sait se servir des autres. La cohérence réduit la formation et les erreurs. (3) MAINTENANCE : les modifications globales deviennent possibles, au lieu d'être renoncées faute de temps. (4) C'est exactement le principe des styles globaux : centraliser plutôt que disperser. En résumé : garantissez la cohérence visuelle en travaillant sur TROIS niveaux complémentaires, tous fondés sur le même principe — centraliser l'apparence au lieu de la répéter écran par écran. La CHARTE GRAPHIQUE applique automatiquement des styles homogènes à tous les champs (et se modifie en un seul endroit) : ne stylisez jamais un champ isolément, modifiez le style. Les MODÈLES DE FENÊTRES portent la structure commune (bandeau, logo, boutons standards, disposition) et se répercutent sur toutes les fenêtres qui en héritent — c'est ce qui rend possible une évolution globale que personne ne ferait à la main sur cinquante écrans. Les FENÊTRES INTERNES et SUPERCHAMPS factorisent les blocs fonctionnels répétés (saisie d'adresse, sélecteur de client, bandeau de filtres), assurant à la fois la cohérence visuelle et l'absence de duplication de code. Complétez par des CONVENTIONS d'équipe écrites (position des boutons, formulation des messages), un VOCABULAIRE homogène — ne pas dire « Client » ici et « Tiers » là — et des comportements constants (Entrée valide, Échap annule). L'enjeu dépasse l'esthétique : une application cohérente inspire confiance, s'apprend plus vite (maîtriser un écran, c'est savoir utiliser les autres) et reste modifiable globalement dans la durée.