# Gray patterns : rester sur le chemin quand le standard ne convient pas > Les standards d'architecture proposent généralement deux issues : s'y conformer, ou obtenir une exception. Les systèmes réels ont besoin d'une troisième option : un écart validé et borné qui garde la cible état de l'art (SOTA) à portée. Source: https://www.bluewise.fr/fr/gray_pattern_to_sota Author: Marc Morel Published: 2026-07-06 Category: Architecture La plupart des équipes d'architecture finissent par publier leurs standards : intégration événementielle, authentification déléguée, contrats versionnés, observabilité native. De bons standards. Puis la réalité se présente. Un système cœur ne produit que des fichiers plats. Un progiciel, acheté pour sa valeur métier, ne supporte que des clés d'API statiques. Un partenaire impose son propre protocole. Le standard ne convient pas, et pas parce que quelqu'un a bâclé le travail. Il y a une raison légitime. À ce stade, la plupart des modèles de gouvernance offrent deux options : - **Se conformer quand même.** Les coûts et les délais grimpent de façon disproportionnée, et parfois le projet s'enlise. Le standard perd sa crédibilité auprès des équipes qu'il est censé servir. - **Accorder une exception.** L'équipe obtient la permission de s'écarter, au cas par cas, sans direction commune. Chaque équipe construit son propre contournement, l'écart fuit dans les contrats, et personne ne peut dire à quel point le paysage s'est éloigné de la cible. Avec le temps, les exceptions tendent à devenir l'architecture réelle, et les standards finissent par décrire un système qui n'existe pas. Je pense qu'il nous manque une troisième catégorie : le gray pattern. ## Ce qu'est un gray pattern Un gray pattern est une variante pré-approuvée et documentée d'un standard. Il accepte un écart local à deux conditions : il préserve l'intention du standard, et il préserve le chemin vers la cible. L'idée centrale est simple : **payer l'écart à la frontière, pas dans le contrat.** Contenir l'écart dans une jointure (un adaptateur, une couche anti-corruption, une gateway) pour que le reste du paysage consomme un contrat conforme. Le système legacy s'écarte. Ses consommateurs, non. Deux exemples. **Un système cœur uniquement batch.** Le standard est l'intégration événementielle, avec des schémas dans un registre. Le système cœur ne peut produire qu'un export nocturne. Exposer ce fichier directement propagerait la contrainte à chaque consommateur. Le gray pattern : un adaptateur lit l'export, calcule les deltas et publie des événements au format cible. Les consommateurs sont conformes dès aujourd'hui, et la latence dégradée est documentée. Quand le système cœur est remplacé, seul l'adaptateur disparaît. **Un progiciel avec des clés statiques.** Le standard est OAuth 2 avec des jetons restreints par audience. Le progiciel n'accepte qu'une clé d'API statique. Le gray pattern : une gateway valide les jetons cibles côté consommateur et substitue la clé côté éditeur. La clé vit dans un coffre, subit une rotation, et chaque accès est journalisé. L'écart est réel, mais il est contenu, contrôlé et réversible. ## Emprunté, pas inventé Rien de tout cela n'est nouveau. PCI DSS formalise depuis longtemps les contrôles compensatoires : quand une exigence ne peut être satisfaite pour une raison légitime, vous démontrez un contrôle alternatif qui couvre le même risque, et vous le revoyez régulièrement. Les gray patterns transposent cette logique à l'architecture. On ne s'écarte pas d'un standard. On s'écarte d'une de ses implémentations, et on montre que le risque qu'il traitait est toujours traité. Pour les organisations régulées, c'est aussi le langage qu'attendent les auditeurs et DORA : un écart identifié, justifié, compensé et suivi. ## Anatomie d'un gray pattern Six champs. Chacun a son poids. 1. **Déclencheur légitime.** Les situations qui le justifient : un legacy qui ne peut pas évoluer, une contrainte éditeur, une décision explicite de valeur métier. 2. **Invariants.** Ce qui reste non négociable (sécurité, traçabilité, résidence des données) et ce qui peut fléchir (protocole, format, technologie). 3. **Contrôle compensatoire.** Comment le risque derrière le standard reste couvert. 4. **Chemin vers la cible.** La jointure de migration, et ce qui est supprimé une fois la contrainte levée. 5. **Expiration et responsable.** Une date de revue, et une personne nommément responsable. 6. **Distance mesurée.** Une fitness function ou un indicateur de dette qui garde l'écart visible. Sans chemin vers la cible, un pattern n'est pas gris. C'est un écart bien documenté. ## Le risque : la normalisation de la déviance En étudiant la catastrophe de Challenger, la sociologue Diane Vaughan a décrit comment un écart toléré une fois devient la nouvelle norme implicite. Les gray patterns y sont exposés par construction, parce qu'ils rendent l'écart confortable. Trois garde-fous aident : - **Expiration obligatoire.** Le renouvellement est explicite et justifié. - **Périmètre strict.** Un gray pattern s'applique au contexte qu'il décrit, jamais par analogie. - **Adoption suivie.** Si un gray pattern apparaît partout, le standard est probablement mal calibré. La correction consiste à revoir le standard, pas à continuer d'émettre des variantes. Ce dernier point est celui auquel je tiens le plus. Les gray patterns agissent comme un capteur : ils font remonter l'écart entre les standards et le terrain, là où les exceptions binaires tendent à le cacher. ## Ce qui change - **Pour les équipes de delivery :** une réponse toute prête au lieu d'un comité de revue. - **Pour l'architecture :** une dette contenue, datée et mesurée. - **Pour les standards eux-mêmes :** une boucle de rétroaction qui les garde ancrés dans la réalité. L'état de l'art n'est pas un état que l'on déclare. C'est une direction que l'on tient. Les bons standards disent aux équipes où aller, et comment continuer d'avancer quand la route est barrée.