Marteen est développeur backend depuis sept ans. Ce matin, il doit modifier la route d’une API qui gère les notifications utilisateurs. Il sait que le responsable du service a changé récemment. Il sait aussi qu’il y a eu une refonte, quelque part. Ce qu’il ne sait pas, c’est où trouver la documentation à jour, qui contacter en cas de problème, et si le service est encore actif ou déjà remplacé. Il passe deux heures à chercher. Il ne code rien.

Cette scène n’est pas un incident isolé. Dans les architectures microservices à grande échelle, elle se répète plusieurs fois par jour, dans chaque équipe, pour chaque développeur. Et ce que l’on appelle communément « perte de temps » porte un nom plus précis : charge cognitive excessive. Un mécanisme documenté, aux conséquences bien réelles sur la santé des équipes.

L’étalement architectural, ou comment la complexité produit du chaos silencieux

Le passage aux microservices a profondément transformé la conception des systèmes informatiques. Plutôt qu’un bloc monolithique, l’application devient un écosystème de services autonomes, chacun responsable d’une fonction précise. L’approche a des vertus réelles : déploiement indépendant, résilience, scalabilité. Mais à mesure que l’organisation grandit, cet écosystème se densifie jusqu’à devenir illisible.

Cinquante services deviennent cent. Cent deviennent cent cinquante. Les équipes changent, les responsables tournent, les documentations vieillissent. Ce phénomène porte un nom dans l’écosystème Atlassian : le « sprawl ». Ou l’étalement incontrôlé des composants techniques. Et il a des conséquences directes sur la santé des équipes, pas seulement sur leur productivité.

L’ergonomie cognitive nous enseigne que le cerveau humain dispose d’une capacité de traitement de l’information limitée. Lorsque l’environnement de travail impose une surcharge informationnelle (trop de services à connaître, trop de contextes à maintenir simultanément, trop d’incertitudes non résolues), les ressources attentionnelles s’épuisent. Ce n’est pas une métaphore : c’est un mécanisme documenté, qui conduit à l’erreur, à la démotivation, et à terme, à l’épuisement professionnel.

Atlassian Compass : un registre vivant pour réduire la friction cognitive

C’est précisément à ce problème qu’Atlassian Compass répond. Non pas comme un catalogue statique que personne ne tient à jour, mais comme un registre de composants vivant et décentralisé, conçu pour redonner aux développeurs ce que le sprawl leur a confisqué : la capacité de naviguer dans leur propre architecture sans faire l’archéologue.

Concrètement, chaque microservice reçoit une carte d’identité structurée : propriétaire, canal de communication, dépôt de code, dépendances. Ces informations ne sont pas stockées dans un wiki oublié. Elles sont connectées aux outils que les équipes utilisent déjà : Jira, Bitbucket, GitHub, Slack. Compass agrège, structure et rend visible ce qui était dispersé.

À cela s’ajoutent deux dispositifs particulièrement utiles. Le premier est le Scorecard : un système de critères de qualité standardisés : « le service a un README », « le build passe », « aucune vulnérabilité critique n’est ouverte ». Il génère un score de santé en temps réel pour chaque composant. Le second est le CheckOps : avant de créer un nouveau service, le développeur suit une liste de vérification automatisée, ce qui réduit les risques de duplication et de dette technique précoce.

L’objectif déclaré est de réduire la charge cognitive. Mais pour que cet objectif soit atteint durablement, il faut comprendre pourquoi cette charge est si difficile à contenir.

La surcharge cognitive comme révélateur d’un déficit d’organisation

Lorsque les exigences professionnelles sont élevées sans marge de manœuvre suffisante pour y répondre, le risque d’épuisement augmente significativement. Le développeur qui cherche pendant deux heures qui maintient un service critique n’est pas inefficace. Il est placé dans une situation où son intelligence est mobilisée pour compenser un désordre organisationnel qui ne lui appartient pas.

Il en résulte un sentiment d’impuissance acquise : « de toute façon, l’architecture est chaotique, je ne peux rien y faire. » Ce sentiment peut conduire au repli. Chacun code dans son coin, sans vérifier si ce qu’il développe existe déjà. Il peut conduire au cynisme : « si ça casse en production, ce n’est pas ma faute, je ne pouvais pas savoir. » Et il prépare le terrain d’un épuisement professionnel d’un type particulier : non pas celui provoqué par un rythme trop soutenu, mais celui qui naît de l’épuisement attentionnel. Compenser indéfiniment le chaos organisationnel par son énergie cognitive finit par vider les réserves.

Le travail invisible de la documentation

La sociologie du travail l’a nommé avec précision : dans toute organisation, certaines tâches sont considérées comme du « sale boulot ». Un sale boulot indispensable, mais peu valorisé, peu visible, peu récompensé. Documenter un microservice appartient souvent à cette catégorie. Prendre le temps d’écrire un README complet, de mettre à jour les dépendances dans Compass, de notifier les changements de responsable : tout cela prend du temps que l’on pourrait passer à « livrer des fonctionnalités ». Les indicateurs de performance mesurent la vélocité, pas la qualité de la documentation. Les reconnaissances vont aux déploiements réussis, pas aux registres bien tenus.

Dans cet environnement, les équipes vont naturellement optimiser pour ce qui est mesuré. Et Compass risque de devenir un outil de conformité plutôt qu’un vrai levier de clarté : les équipes obtiendront un bon score Scorecard avec une documentation minimale qui passe les critères, mais qui ne répond pas aux questions réelles des développeurs. C’est pourquoi Compass ne peut fonctionner durablement que dans une culture qui reconnaît la maintenance comme un travail à part entière, valorisé et alloué explicitement dans le cycle de développement.

Vers une architecture cognitivement soutenable

Déployer Compass est un point de départ solide. En faire un levier durable suppose quelques conditions organisationnelles que l’outil seul ne peut pas créer. La première est de mesurer ce que l’on veut améliorer : non seulement la vélocité des équipes, mais le temps moyen nécessaire pour trouver une information sur un service, le taux de duplication involontaire de composants, le niveau de satisfaction des développeurs sur la lisibilité de l’architecture. Dans le cas présent, ce que l’on ne mesure pas, on ne l’améliore pas.

La deuxième est de limiter la prolifération des microservices en amont. Compass organise mieux ce qui existe, mais si l’architecture comporte cent cinquante services parce que personne n’a posé la question « en avions-nous vraiment besoin ? », l’outil ne changera pas le problème de fond. La simplicité est une décision architecturale. Et parfois, la meilleure réponse au sprawl est la consolidation, pas la cartographie.

La troisième condition est de reconnaître publiquement les mainteneurs de Compass : ces développeurs qui prennent le temps de mettre à jour les fiches, de faire remonter les incohérences, de former leurs pairs. Ils font un travail invisible qui bénéficie à toute l’organisation. Le rendre visible, dans les rétrospectives, dans les évaluations, dans les communications d’équipe, est une condition de sa pérennité.

La question importante n’est pas technique. Elle est organisationnelle : votre entreprise reconnaît-elle que la charge cognitive des développeurs est un enjeu de santé au travail, ou la traite-t-elle comme une simple variable d’optimisation de la productivité ? Compass peut aider. Mais c’est la culture qui décide si l’outil sera utilisé ou contourné.