Pour présenter une architecture technique, montrez dans cet ordre la place du système, le parcours d’une requête importante, puis les raisons de préférer une option aux autres. Terminez par la décision attendue. Un schéma de composants, à lui seul, n’explique ni le fonctionnement ni les compromis.
L’exemple ci-dessous concerne le service de commandes d’un commerçant fictif. L’équipe envisage d’introduire une file de messages entre l’acceptation de la commande et son traitement logistique. La présentation doit aider les équipes techniques et d’exploitation à décider si elles lancent un pilote ; elle ne décrit pas un système réel en production.
Une fois les schémas et la comparaison prêts, vous pouvez transformer le plan d’architecture en diapositives modifiables avec Presenti. Fournissez le raisonnement technique : le premier brouillon aura ainsi une histoire utile à organiser, au lieu de demander à l’IA d’inventer un système.
Formulez le changement que le public doit accepter
Écrivez la décision avant de créer une diapositive : « Approuver un pilote de traitement logistique asynchrone des commandes acceptées, sans modifier le parcours actuel d’autorisation du paiement. » Précisez le périmètre : l’intégration du prestataire de paiement, le remplacement de la base de données et la refonte complète du passage en caisse ne font pas partie de cette discussion.
Cette phrase détermine les détails à inclure. Le responsable de l’exploitation doit comprendre comment apparaît un traitement logistique retardé. Le responsable technique doit savoir comment seront gérés les nouvelles tentatives et les doublons. Aucun des deux n’a besoin d’une visite de tous les services de l’entreprise. Si le comportement attendu de l’utilisateur reste contesté, clarifiez-le dans une présentation des exigences produit avant de demander à cette revue de choisir une architecture.
Commencez par les systèmes voisins
La vue de contexte montre le client, l’application de commande, le service de commandes, le prestataire de paiement et le service logistique. Indiquez le rôle des relations, pas seulement des flèches. « Autorise le paiement » est plus parlant que « API ». Délimitez le service de commandes, objet de la discussion, et placez les systèmes externes hors de ce périmètre.
Les recommandations C4 sur le diagramme de contexte proposent cette vue d’ensemble du système, de ses utilisateurs et des systèmes connectés avant les détails techniques. Il n’est pas nécessaire d’adopter tous les diagrammes C4 pour séparer ainsi les niveaux de lecture.
Suivez une commande jusqu’à son traitement logistique
Un parcours numéroté permet d’expliquer ce que change la file de messages. Voici un flux d’exemple pour ce commerçant fictif. Les numéros doivent correspondre à ceux du schéma pour que l’intervenant puisse désigner une étape sans chercher le bon bloc.
| Étape | Interaction | Ce que le public doit comprendre |
|---|---|---|
| 1 | L’application de commande envoie une requête au service de commandes | Un identifiant de commande permet de suivre la requête tout au long du parcours |
| 2 | Le service de commandes confirme l’autorisation du paiement | Un paiement refusé ne déclenche pas de traitement logistique |
| 3 | Le service enregistre la commande acceptée et un événement en attente | La conception doit prévoir une panne entre l’enregistrement de la commande et la publication de l’événement |
| 4 | Un composant de publication envoie l’événement à la file | La publication peut être retentée ; l’événement doit conserver un identifiant stable |
| 5 | Le service logistique reçoit l’événement et enregistre son état de traitement | La réception répétée du même événement ne doit pas entraîner une seconde expédition |
| 6 | L’exploitation consulte l’état du traitement ou une alerte d’échec | La file modifie aussi la surveillance et la reprise après incident, pas seulement le parcours de la requête |
Un diagramme dynamique C4 représente les interactions ordonnées d’un cas d’usage. Utilisez-le là où il apporte quelque chose : ici, les chemins d’échec et de nouvelle tentative comptent davantage que chaque appel réussi.
N’intitulez pas cet exemple « Traitement exactement une fois » ou « Aucune commande perdue ». Ces affirmations exigeraient des détails d’implémentation et des tests absents de la présentation. Posez plutôt les questions de conception : comment récupérer les événements en attente, combien de temps conserver les traitements échoués et qui prend en charge leur relance ?
Comparez les options avec les mêmes critères
Évitez de juxtaposer un paragraphe d’avantages et un paragraphe d’inconvénients. Appliquez les mêmes critères aux deux options et faites apparaître le coût de chacune.
| Critère | Appel direct au service logistique | Traitement via une file |
|---|---|---|
| Réponse au client | L’acceptation dépend du comportement de l’appel au service logistique | L’acceptation peut être séparée du traitement ultérieur |
| Reprise après incident | Les nouvelles tentatives restent dans le parcours de l’appelant | Il faut gérer l’état des traitements, leur relance et les doublons |
| Travail d’exploitation | Ce flux comporte moins d’éléments à gérer | La santé de la file, les échecs et le retard de traitement nécessitent des responsables |
| Migration | Pas de nouveau parcours de messages | Un pilote et une procédure de retour arrière sont nécessaires |
Ce tableau expose des considérations de conception, pas des performances mesurées. N’ajoutez des données de latence ou d’erreur que si vous pouvez préciser l’environnement, la période, l’échantillon et la source. Sans ces données, recommandez un pilote limité plutôt qu’une amélioration présentée comme acquise.
Organisez le raisonnement en six diapositives
- Décision et périmètre : le pilote proposé et ses exclusions.
- Contexte : le service de commandes et ses voisins directs.
- Problème actuel : l’incident, le retard ou la contrainte d’exploitation observés à l’origine de la proposition.
- Parcours proposé : les six interactions et les points de défaillance.
- Options : les quatre mêmes critères de comparaison pour les deux approches.
- Décision sur le pilote : responsable, retour arrière, tests et date de la réunion de décision.
Dans cet exemple, la dernière diapositive peut demander à l’équipe plateforme de tester une panne du composant de publication, une livraison en double et une indisponibilité du service logistique avant la réunion de décision. Chaque test a besoin d’un résultat attendu et d’une personne chargée de l’interpréter. La réunion aboutit ainsi à quelque chose de concret, sans prétendre que la présentation tranche à elle seule l’architecture. Une fois ces tests réalisés, une présentation de préparation à la mise en production relie leurs résultats à la version candidate précise, aux points bloquants restants et à la personne habilitée à décider du lancement.
Créez le brouillon de six diapositives dans Presenti à partir de votre parcours, de votre tableau comparatif et des conditions du pilote. Placez la configuration, les journaux et les résultats complets des tests en annexe ou dans un document de conception lié : les lecteurs pourront les consulter sans alourdir le fil principal.
