Demandes de changement d'architecture : des Pull Requests pour votre modèle C4
Le mois dernier, un ingénieur d'une équipe que je conseille a renommé un service central sur leur diagramme d'architecture. Pas de discussion. Pas de revue. Le changement était en ligne instantanément, et trois équipes ont passé le standup suivant à se demander si le vrai service avait été renommé ou juste le diagramme. Ce n'était pas le cas. Quelqu'un avait simplement trouve le label peu clair et l'avait "corrigé".
Cet incident a cristallisé quelque chose à quoi nous réfléchissions depuis un moment. Le code a ses pull requests. L'infrastructure a plan/apply. Les schémas de base de données ont leurs migrations. Mais les diagrammes d'architecture ? N'importe qui avec un accès en édition peut modifier n'importe quoi, à n'importe quel moment, et le reste de l'équipe le découvre... un jour.
Aujourd'hui, ça change. Les Demandes de Changement d'Architecture apportent le workflow de pull request à votre modèle C4.
Comment ça fonctionne
Le concept est volontairement familier. Si vous avez déjà ouvert une pull request sur GitHub, vous savez déjà comment ça marche.
Vous commencez par créer une demande de changement. Donnez-lui un titre, décrivez ce que vous proposez et pourquoi. Puis ajoutez vos modifications : créer de nouveaux systèmes, mettre à jour des conteneurs existants, supprimer des composants inutilisés, modifier des relations. Chaque changement est une opération discrete : création, mise à jour ou suppression sur un élément C4 spécifique.
La demande de changement commence en brouillon. Vous pouvez continuer à ajouter et affiner les changements jusqu'à ce que vous soyez prêt. Quand la proposition est complète, vous l'ouvrez pour revue.
Vos collègues voient la demande ouverte dans la liste des demandes de changement du projet. Ils peuvent examiner chaque modification proposée, voir exactement ce qui est crée, modifie ou supprime. Ils laissent des revues : approuver, demander des modifications ou commenter. Une fois le nombre d'approbations requis atteint, la demande peut être fusionnée, appliquant tous les changements au modèle C4 en une seule opération atomique.
Aperçu visuel
Une chose que nous ne voulions pas, c'était une vue diff qui ressemble à un blob JSON. L'architecture est visuelle, et la revue des changements d'architecture devrait l'être aussi.
Chaque demande de changement inclut un aperçu en direct du diagramme. L'aperçu rend le modèle C4 actuel avec toutes les modifications proposées superposées. Les nouveaux éléments apparaissent avec un surlignage vert. Les éléments modifiés reçoivent un anneau ambre. Les éléments supprimés affichent un indicateur rouge. Vous pouvez naviguer à travers les niveaux C4, système, conteneur, composant, code, et voir l'impact complet de la proposition à chaque profondeur.
C'est le même canevas interactif React Flow que vous utilisez pour le diagramme en direct, avec le même drill-down, zoom et panoramique. La seule différence, ce sont les données : c'est une projection calculée de ce à quoi l'architecture ressemblera après la fusion.
Le processus de revue
Les revues suivent un modèle simple. Un relecteur peut :
- Approuver — "Ça me va, fusionnez quand c'est prêt."
- Demander des modifications — "J'ai des préoccupations, discutons avant que ça soit intégré."
- Commenter — "Pas d'objection, mais voici un peu de contexte."
Chaque revue inclut un champ texte libre pour des retours détaillés. La demande de changement suit son nombre d'approbations par rapport au seuil requis du projet. Par défaut, une approbation est nécessaire, mais vous pouvez configurer cela par projet : zéro approbation pour les petites équipes qui veulent un suivi léger, deux ou trois pour les grandes organisations qui ont besoin d'une validation formelle.
Mode demandes uniquement
Pour les équipes qui veulent aller plus loin, nous avons ajouté un Mode demandes uniquement dans les paramètres du projet. Lorsqu'il est activé, les modifications directes du modèle C4 sont verrouillées. Le seul moyen de modifier l'architecture est via une demande de changement.
Cela ne signifie pas que le diagramme devient en lecture seule. Vous pouvez toujours naviguer, explorer, lier des ADR et de la documentation aux éléments, ajouter des commentaires. Vous ne pouvez simplement pas déplacer, renommer, créer ou supprimer des éléments sans passer par le workflow de demande de changement.
Nous avons construit cela pour les organisations ou la gouvernance de l'architecture compte : les industries réglementées, les grandes équipes d'ingénieurs, les équipes plateforme gérant une infrastructure partagée. L'architecture devient un artefact contrôle, avec chaque modification traçable et revue.
Suivi d'activité
Chaque événement du cycle de vie d'une demande de changement apparaît dans l'onglet Activité du projet. Quand une demande est ouverte, fermée, rouverte ou fusionnée, une entrée d'historique est enregistrée avec l'auteur, l'horodatage et le titre de la demande. Cela vous donne une chronologie de l'évolution de l'architecture, pas seulement à quoi elle ressemble aujourd'hui, mais la séquence de propositions et de décisions qui l'ont façonnée.
Combiné avec les ADR et les liens de documentation, vous obtenez un récit complet : ce qui a changé (la demande de changement), pourquoi ça a changé (l'ADR), et comment ça s'intègre dans le contexte plus large (la documentation).
Construire des changements
Le constructeur de changements vous permet de construire des propositions élément par élément. Pour chaque changement, vous spécifiez :
- Opération : création, mise à jour ou suppression
- Type d'élément : système, conteneur, composant, élément de code, relation ou overlay
- Données de l'élément : la spécification complète de l'élément, nom, description, technologie, type, et tous les champs que vous rempliriez en le créant directement
Pour les mises à jour, le système capture à la fois l'état actuel et l'état propose, pour que les relecteurs voient exactement ce qui change. Pour les suppressions, les données de l'élément existant sont conservées dans la demande pour référence.
Vous pouvez mélanger les opérations librement. Une seule demande de changement peut créer deux nouveaux conteneurs, mettre à jour une relation et supprimer un composant obsolète. Lors de la fusion, tous les changements s'appliquent ensemble.
Ce que ça signifie pour les équipes
Les demandes de changement d'architecture ne sont pas la pour ajouter de la bureaucratie. Elles sont la pour rendre l'évolution architecturale intentionnelle.
Dans un codebase, la pull request n'est pas qu'une barrière, c'est un outil de communication. Elle dit "voici ce que je propose, voici pourquoi, qu'en pensez-vous ?" Elle crée un moment naturel pour le partage de connaissances, pour détecter les erreurs tôt, pour construire une compréhension partagée.
L'architecture mérite le même traitement. Quand quelqu'un propose d'ajouter un nouveau service, c'est une conversation qui vaut la peine d'avoir avant qu'il apparaisse sur le diagramme. Quand quelqu'un veut restructurer la hiérarchie des composants, l'équipe devrait voir l'ensemble du tableau avant que ça devienne la nouvelle réalité.
La demande de changement, c'est cette conversation, rendue structurée et traçable.
Pour commencer
Les Demandes de Changement d'Architecture sont disponibles dès maintenant sur tous les plans équipe. Naviguez vers n'importe quel projet, et vous trouverez la section "Demandes" dans la barre latérale. Créez votre première demande, ajoutez quelques changements, et ouvrez-la pour revue.
Si vous voulez imposer le workflow, activez le Mode demandes uniquement dans les paramètres de votre projet. Configurez le nombre d'approbations requis selon les besoins de gouvernance de votre équipe.
Votre architecture est une décision d'équipe. Maintenant, vos outils le rendent explicite.
Vous voulez en savoir plus sur l'architecture collaborative ? Découvrez la Collaboration en temps réel sur les diagrammes C4, ou apprenez comment les Architecture Decision Records complètent les demandes de changement en capturant le "pourquoi" derrière chaque évolution architecturale.