L'architecture dans votre inbox : le récap d'équipe hebdomadaire
Le score de drift sur notre service Payment monte depuis six semaines. Deux ADRs sont ouvertes et attendent revue. Une violation de conformité critique est apparue lundi. Le nouveau service Inventory a été attribué à une équipe qui n'existe pas encore.
Je sais tout ça parce que je me suis connecté à archyl ce matin et que j'ai cliqué à travers cinq pages.
La plupart des ingénieurs de ces équipes n'en savent rien.
C'est le problème qu'on a décidé de résoudre cette semaine. Les insights d'architecture — drift, conformité, ADRs, décisions, discussions — existent dans archyl. Ils sont indexés, calculés, exposés dans des dashboards. Mais les personnes qui en ont le plus besoin sont la tête dans le code, pas en train de rafraîchir des dashboards. Du coup, les insights restent où ils sont, et les décisions architecturales continuent de se prendre dans le vide.
Aujourd'hui on livre le Récap d'architecture d'équipe. Un email récurrent qui apporte le statut architecture de chaque équipe à l'inbox de l'équipe qui en est propriétaire. Hebdomadaire, toutes les deux semaines, ou mensuel. L'équipe choisit.
Les dashboards perdent. L'inbox gagne.
Il y a une raison pour laquelle GitHub vous envoie encore des emails sur les pull requests en 2026 même si le site est juste là. Il y a une raison pour laquelle Linear envoie un récap quotidien. Il y a une raison pour laquelle chaque outil d'analytics propose un "weekly summary".
Les gens ne tirent pas. Ils scannent ce qui arrive. Un dashboard que vous devez vous souvenir d'ouvrir est un dashboard que vous oubliez d'ouvrir.
Pendant dix ans on nous a dit que "Slack et les dashboards ont tué l'email." Mais les dashboards sont géniaux quand vous savez ce que vous cherchez, et Slack est génial quand vous devez réagir. Aucun des deux n'est bon pour le "voici tout ce qui a compté, en deux minutes" hebdomadaire — qui est exactement ce dont une équipe d'ingénierie a besoin pour rester alignée sur son architecture sans en faire une réunion.
L'email, ironiquement, est la bonne surface. Calme, dense, archivable, recherchable, transférable. Et chaque équipe a déjà une liste de diffusion.
Contenu d'un récap
Le récap de chaque équipe est scopé aux projets qu'elle possède. Rien d'inutile, rien venant d'un autre périmètre.
À l'intérieur, jusqu'à sept sections — l'équipe choisit lesquelles garder :
- Santé de l'architecture — score de drift avec delta vs période précédente, taux de conformité, nombre de déploiements, lead time, MTTR. Le snapshot DORA, sur une seule ligne.
- Changements d'architecture — quels éléments C4 ont été ajoutés, modifiés ou supprimés. Top items.
- Décisions (ADRs) — ce qui a été proposé, ce qui a été mergé.
- Pull requests — Architecture Change Requests par statut.
- Conformité — nouvelles violations, avec sévérité.
- Discussions — nouveaux fils de commentaires ouverts sur les éléments d'architecture. La vue "qu'est-ce qui se débat en ce moment".
- Insights — insights d'architecture générés sur la période.
Les sections sans activité sont silencieusement omises. Pas d'email à moitié vide.
Le rendu est du HTML simple. Pas de pixel de tracking, pas de chrome marketing. Noir sur blanc, monochrome, avec le wordmark archyl en haut — parce que les emails transactionnels devraient ressembler à du Linear ou du Vercel, pas à une campagne. Le mode sombre s'active automatiquement quand votre client email supporte prefers-color-scheme.
La configuration prend quinze secondes
Ouvrez les paramètres de l'équipe, allez dans l'onglet Récap. Saisissez un email d'équipe. Choisissez une fréquence, un jour, une heure, et le fuseau horaire dans lequel l'équipe vit réellement. Cochez les sections. Enregistrez.
Vous pouvez prévisualiser l'email dans l'app sans rien envoyer, et envoyer un test à l'adresse configurée pour vérifier la délivrabilité et le rendu avant d'activer la planification.
Le planificateur tourne toutes les heures et expédie chaque récap à l'heure locale configurée. Un récap hebdo prévu pour le lundi 9h en Europe/Paris arrive à 9h heure de Paris — même si Paris est en heure d'été, même si vous êtes une instance self-hosted qui tourne en America/Los_Angeles. Chaque récap suit l'horloge de l'équipe à qui il appartient.
Pourquoi c'est important
L'architecture est une propriété d'équipe. Elle est possédée collectivement, et elle évolue chaque fois qu'un de ses propriétaires ship du code. Le problème le plus dur n'est pas de capturer l'architecture — diagrammes, ADRs, détection de drift, tout ça on le fait depuis des années. Le problème le plus dur, c'est fermer la boucle entre ce que l'architecture dit et ce que l'équipe sait.
Un récap hebdomadaire fait quelque chose de simple mais rare : il offre à l'équipe un seul moment de cinq minutes, chaque semaine, pour être sur la même page concernant sa propre architecture. Pas de standup. Pas d'outil à ouvrir. Pas d'habitude à construire. Juste l'email que tout le monde lit déjà.
Si vous êtes engineering manager, ce moment vaut de l'or. Si vous êtes ingénieur dans l'équipe, c'est la première fois que le contexte d'architecture vient à vous au lieu de vous faire courir après.
Disponible maintenant
Les récaps d'architecture d'équipe sont disponibles pour toutes les équipes. Ouvrez les paramètres de l'équipe, allez dans l'onglet Récap, et votre premier récap part au prochain tick planifié.
Dites-nous ce que votre équipe en pense. On prototype déjà des équivalents Slack et Teams pour les organisations qui préfèrent le chat à l'inbox — mais pour la cadence hebdomadaire, on est convaincus que l'inbox est la surface qui délivre le contexte sans devenir du bruit.
L'architecture, enfin, là où vivent les gens qui en sont propriétaires.
Vous voulez creuser comment le contexte d'architecture circule dans une équipe d'ingénierie ? Lisez l'article sur les Architecture Change Requests pour le workflow pull request appliqué à votre modèle C4, ou Architecture Chat pour poser n'importe quelle question sur votre stack et obtenir une réponse ancrée dans votre propre modèle.