📜 Règles de Développement
Ensemble des règles stratégiques à respecter pour tout nouveau développement, garantissant la qualité, la traçabilité et la cohérence des livrables.
Validation obligatoire de l'Architecte
Tout nouveau développement ou évolution significative doit être validé par l'Architecte avant le démarrage des travaux. Cette validation couvre le design technique, l'intégration au SI existant et le respect des standards.
Des choix techniques ou stratégiques non validés peuvent compromettre la cohérence du SI, générer de la dette technique lourde et provoquer des incompatibilités coûteuses à corriger une fois le développement engagé. Cette validation permet également de lutter contre le Shadow IT en évitant la prolifération de solutions non référencées, non maintenues et hors de tout contrôle.
Consultation obligatoire du RSI métier
Tout nouveau projet ou évolution significative doit faire l'objet d'une consultation du Responsable SI Métier concerné avant le démarrage des travaux. Cette consultation porte sur l'alignement métier, la priorisation, les impacts opérationnels et la validation du besoin.
Le RSI métier est le garant de la cohérence entre les besoins exprimés et la stratégie métier du domaine. Sans sa consultation, un projet risque de dupliquer des initiatives existantes ou d'être mal positionné dans le portefeuille métier.
Comité des normes technologiques
Les choix technologiques structurants (nouveau framework, nouveau service, changement d'infrastructure) doivent être présentés à l'Architecte, qui les validera en se référant aux décisions du Comité des normes technologiques.
Un choix technologique non concerté peut fragmenter le SI, multiplier les compétences requises et créer des silos de maintenance. Le comité garantit la cohérence globale et la pérennité des décisions techniques.
Relecture et validation du modèle de données
Le modèle de données (schéma conceptuel et physique) doit être relu et validé avant le démarrage du développement. Cette validation est réalisée par l'Architecte et/ou un Techlead.
Un modèle de données non validé peut entraîner des incohérences structurelles, des problèmes de performance et une dette technique lourde à corriger une fois le développement engagé. La relecture garantit la normalisation, la cohérence avec le SI existant et l'adéquation aux besoins fonctionnels.
Référencement dans le portefeuille applicatif
Toute nouvelle application ou évolution majeure doit être référencée dans l'ApplicationLandscape, notre site de cartographie du portefeuille applicatif. La fiche doit inclure le périmètre fonctionnel, la stack technique, les dépendances et le responsable.
Sans référencement, une application devient invisible pour les équipes transverses : pas de suivi de maintenance, pas de gestion des dépendances, pas de vision globale du SI. C'est la porte ouverte au Shadow IT et aux redondances coûteuses.
Vue de déploiement obligatoire
Chaque projet doit produire une vue de déploiement au format UML dans Enterprise Architect, décrivant l'infrastructure cible, les composants déployés et leurs interactions.
La vue de déploiement permet d'anticiper les contraintes d'infrastructure, de sécuriser les mises en production et de disposer d'une cartographie à jour du SI. Sans elle, les équipes opèrent à l'aveugle lors des déploiements et de la maintenance.
Respect des bonnes pratiques DevHub
Les équipes doivent se référer aux articles de bonnes pratiques publiés sur DevHub, notre référentiel d'architecture technique, et les respecter. Ces articles couvrent notamment la gestion du code source, les conventions de nommage, les stratégies de branching et les pratiques de développement.
DevHub centralise les standards techniques validés par l'équipe Techlead. S'y référer garantit l'homogénéité des pratiques entre les équipes, évite les dérives et assure que chaque développeur dispose d'une source de vérité unique et à jour.
Revue de code systématique
Aucun code ne peut être intégré sans revue par au moins un pair. La revue vérifie la conformité aux standards, la lisibilité, la sécurité et la cohérence architecturale.
La revue de code est le dernier filet de sécurité avant intégration. Elle réduit significativement les défauts en production, favorise le partage de connaissances au sein de l'équipe et empêche la dépendance à un seul développeur.
Traçabilité des changements
Chaque commit doit référencer le ticket ou la user story associée. Les messages de commit doivent suivre une convention claire et homogène.
La traçabilité permet de relier chaque modification au besoin métier qui l'a motivée. En cas d'incident ou d'audit, elle offre une piste claire pour comprendre quand, pourquoi et par qui un changement a été introduit.
Aucun secret dans les dépôts
Aucune donnée sensible (mots de passe, clés API, tokens, chaînes de connexion) ne doit être stockée dans un dépôt Git ou tout autre gestionnaire de sources. Les secrets doivent être gérés via des coffres-forts dédiés (Azure Key Vault, variables CI/CD protégées, etc.).
Un secret exposé dans un dépôt, même privé, peut être extrait par erreur, fuiter lors d'un partage de code ou persister indéfiniment dans l'historique Git. Les conséquences vont de la compromission de systèmes à la violation de données clients.
Tests unitaires obligatoires
Tout nouveau code livré doit être accompagné de tests unitaires. Le seuil minimal de couverture est défini par projet et contrôlé automatiquement via le pipeline CI/CD.
Les tests unitaires détectent les régressions au plus tôt, réduisent le coût de correction des défauts et sécurisent les évolutions futures. Sans eux, chaque modification devient un risque pour la stabilité de l'application.
Analyse statique du code
Le code doit passer les contrôles d'analyse statique (SonarQube) sans dette technique critique. Les Quality Gates doivent être respectées avant toute mise en production.
L'analyse statique identifie automatiquement les vulnérabilités, les mauvaises pratiques et la dette technique avant qu'elles n'atteignent la production. Elle constitue un contrôle objectif et reproductible de la qualité du code.
Pipeline CI/CD actif
Chaque projet doit disposer d'un pipeline d'intégration et de déploiement continu opérationnel, incluant compilation, tests automatisés, analyse de qualité et déploiement vers les environnements cibles.
Un pipeline CI/CD automatise les contrôles qualité et élimine les erreurs liées aux déploiements manuels. Il garantit que chaque livraison passe par les mêmes étapes de validation, réduisant les incidents en production.