EX-00 / Exemple de livrable · Produit fictif · Aucun travail client
Exemple d’évaluation de la livraison et de l’appropriation React
Cet exemple fictif concerne la Plateforme SaaS Exemple. Il a été créé pour montrer la structure et la qualité de décision du livrable. Il ne s’agit pas d’un vrai rapport client et aucun constat, personne, système ou résultat ne décrit une entreprise réelle.
EX-01
Synthèse exécutive
La Plateforme SaaS Exemple dispose d’une équipe produit compétente et d’une application React qui continue à produire de la valeur pour ses utilisateurs. Le risque de livraison augmente parce que trois sujets frontend — données distantes, état des parcours et validation des formulaires — sont gérés différemment dans des modules voisins.
La recommandation fictive n’est pas une réécriture. Les 30 premiers jours doivent valider une frontière applicative commune dans un parcours représentatif, protéger son comportement actuel et transférer la décision à l’équipe avant de l’étendre.
EX-02
Vue d’ensemble de l’architecture
Situation actuelle
Les composants de route récupèrent directement les données, plusieurs hooks personnalisés dupliquent les règles d’état serveur, les formulaires mêlent validation et orchestration réseau, et les composants partagés acceptent des comportements propres au produit par des propriétés de plus en plus larges.
Observation sur l’appropriation
Deux développeurs seniors sont régulièrement sollicités pour interpréter les décisions de flux de données et de frontières de composants après le début de l’implémentation. La revue est devenue l’endroit où l’architecture est découverte.
Frontière cible recommandée
Garder la composition des routes légère, placer le comportement des parcours dans un module applicatif typé, isoler les opérations sur les données distantes derrière une frontière de requêtes unique et préserver les primitives d’interface partagées des règles propres au produit.
EX-03
Exemple de registre des risques
R-01 · Goulot de décision · Priorité élevée
Les décisions importantes sur les données et les parcours dépendent de deux relecteurs. Le travail peut démarrer sans leur contexte, mais ne peut se terminer avec confiance sans reprise tardive.
R-02 · Modèles d’état concurrents · Priorité élevée
Des parcours voisins utilisent des effets locaux, un store global et des mutations du cache de requêtes pour des comportements d’état serveur comparables. Les défauts sont difficiles à reproduire et les corrections se transfèrent mal.
R-03 · Couplage des composants partagés · Priorité moyenne
Les composants réutilisables reçoivent des indicateurs et callbacks propres au produit. Le risque de changement augmente, mais la frontière actuelle peut être améliorée progressivement.
R-04 · Couverture sans responsabilité claire · Priorité moyenne
Des tests existent, mais plusieurs protègent des détails d’implémentation plutôt que le comportement des parcours nécessaire à une refonte sûre.
EX-04
Exemple de constat prioritaire
Constat 01 · Établir une frontière de responsabilité pour un parcours
Observation : le même parcours est réparti entre des effets de route, des gestionnaires de formulaire, des callbacks de cache et des composants partagés.
Conséquence sur la livraison : les développeurs ne trouvent pas un endroit unique pour raisonner sur le chargement, la validation, la mutation, la récupération et l’invalidation.
Recommandation : déplacer un parcours représentatif dans un module applicatif typé avec entrées explicites, opérations de données distantes, validation et états d’interface.
Vérification : un développeur intermédiaire doit pouvoir implémenter le deuxième parcours à partir de la frontière documentée sans nouvelle décision d’architecture.
EX-05
Modèle de priorité
- Critique : risque actuel de sécurité, d’intégrité des données ou de mise en production qui empêche une livraison sûre.
- Élevée : source répétée de retard, de régression ou de concentration de responsabilité.
- Moyenne : coût de maintenabilité significatif à traiter après la première frontière validée.
- Faible : amélioration utile avec peu d’effet sur le prochain changement produit important.
La priorité reflète la conséquence pour le produit et la livraison, pas le degré de désordre apparent d’un fichier.
EX-06
Décision d’architecture recommandée
ADR-EX-01 · Porter le comportement des parcours dans des modules applicatifs
Décision : les parcours produit portent l’orchestration, la validation, les opérations de données distantes et les états de récupération dans des modules applicatifs typés. Les routes composent ces modules ; les composants d’interface partagés rendent l’état sans porter les règles produit.
Pourquoi maintenant : cette frontière traite le coût de décision récurrent le plus élevé et peut être validée sans modifier toute l’application.
Compromis : l’équipe maintiendra temporairement un modèle cible à côté des anciens. Son adoption reste limitée aux parcours touchés jusqu’à ce que l’exemple prouve sa valeur.
Alternative écartée : remplacer toute la gestion d’état augmenterait la surface de changement avant d’avoir compris le problème d’appropriation.
EX-07
Plan d’implémentation proposé sur 30 jours
Jours 1 à 5 · Référence et décision
Cartographier le parcours représentatif, consigner le comportement actuel, identifier ses responsables et valider l’ADR ainsi que les preuves attendues.
Jours 6 à 12 · Implémentation représentative
Implémenter la frontière applicative, protéger les comportements importants et rendre visibles les états de chargement, vide, échec, récupération et réussite.
Jours 13 à 18 · Application par l’équipe
Travailler en binôme avec un développeur sur un deuxième parcours plus petit. Consigner ce qui est clair dans le modèle cible et ce que l’ADR doit préciser.
Jours 19 à 24 · Revue et outillage
Mettre à jour les règles de revue, les exemples et les contrôles d’architecture légers. Ne supprimer que les duplications rendues inutiles par l’implémentation validée.
Jours 25 à 30 · Passation et séquence suivante
Examiner les preuves, attribuer la responsabilité, choisir le prochain parcours prioritaire et décider si un appui externe à l’implémentation apporte encore de la valeur.
EX-08
Considérations de passation
- Nommer le responsable interne de la décision et les développeurs capables de l’appliquer.
- Conserver l’ADR près du code représentatif et de la liste de contrôle de revue.
- Consigner explicitement les exceptions au lieu de les cacher dans des implémentations ponctuelles.
- Réévaluer l’ordre des priorités lorsque les plans produit ou les responsabilités de l’équipe changent.
- Mettre fin à l’appui externe lorsque l’équipe sait appliquer et remettre en question le modèle de façon autonome.
EX-09
Demander l’évaluation réelle
Votre évaluation utiliserait votre produit, votre dépôt, vos contraintes de livraison et votre modèle d’appropriation. Elle ne réutiliserait pas ces constats fictifs comme verdict générique.
Demander une évaluation