La croissance est la partie dont nous savons habituellement parler. On ajoute des équipes. On crée des frontières d'ownership. On introduit du travail de plateforme. On sépare des systèmes pour que les gens puissent avancer plus vite sans se marcher dessus chaque jour. Pendant un certain temps, notre architecture et notre organisation allaient dans la même direction. Avant 2015, nous étions autour de 56 développeurs. Nous avions assez de personnes, assez de secteurs de produit et assez de spécialisation pour que plus de séparation semble naturelle.
Les secteurs de produit avaient des réalités différentes. Les paiements avaient la leur. Le mailer avait la sienne. Le media buying et le media traffic avaient aussi la leur. Les paysites étaient plus compliqués, parce que plusieurs équipes travaillaient dans le même espace produit et partageaient souvent la même base de code, mais la forme générale restait compréhensible. Nous avions une équipe plateforme responsable du coeur du système paysite, et les autres équipes devaient construire par-dessus cette fondation.
Ce n'était pas parfait. L'équipe plateforme devait convaincre les autres équipes de suivre sa direction, et les équipes plus proches des parties prenantes avaient parfois de bonnes raisons de pousser les limites. Les parties prenantes demandaient des fonctionnalités qui se chevauchaient, se contredisaient, ou réglaient le même problème sans savoir qu'une autre demande existait déjà. Nous avons essayé des rencontres d'architecture. Nous avons essayé de nommer des champions. Nous avons essayé de créer les conversations qui garderaient le système cohérent. Une partie a fonctionné, mais le flot n'a jamais été fluide parce que l'ownership n'était jamais aussi clair que l'organigramme le laissait croire.
Avec du recul, les idées de Team Topologies donnent un langage utile pour ce que nous vivions. Certaines équipes étaient alignées sur un flux produit. L'équipe plateforme essayait de réduire la charge cognitive en donnant aux autres équipes une fondation commune. En théorie, cela devait aider. En pratique, le mode d'interaction ressemblait souvent plus à de la négociation qu'à de l'accompagnement. L'équipe plateforme pouvait avoir l'air de bloquer quand elle poussait pour la cohérence, et les équipes produit pouvaient avoir l'air indisciplinées quand elles poussaient pour aller vite localement. Les deux lectures étaient trop simples. Le vrai problème était que les frontières d'architecture et d'équipe étaient encore en train d'être découvertes pendant que l'entreprise continuait d'avancer.
Ensuite, l'entreprise a dû réduire sa taille. La réalité financière a changé, et l'organisation a dû se réduire. Nous sommes passés d'environ 56 développeurs avant 2015 à autour de 40 en 2016. La partie ironique, s'il y en a une, c'est que les systèmes ne disparaissent pas quand les équipes disparaissent. Leur roadmap peut ralentir, leurs propriétaires peuvent changer, mais les systèmes en production sont encore là. Ils ont encore besoin de correctifs, de déploiements, de mises à jour de runtime, de support, et de quelqu'un qui se souvient pourquoi une décision a été prise.
Nous nous sommes restructurés. Les paiements et le media traffic ont gardé leurs responsabilités, mais le groupe paysite a hérité de plusieurs autres systèmes. Quatre équipes de développement sont devenues deux, et l'équipe plateforme est restée pendant un certain temps. Les conversations sont devenues plus faciles parce qu'il y avait moins d'équipes, mais un autre changement a compté autant : la structure des parties prenantes a changé. Un PMO a commencé à filtrer et centraliser les demandes. Cela ne réglait pas tout, mais cela réduisait les demandes concurrentes et donnait une façon plus claire de mesurer ce qui comptait. Pendant quelques années, le modèle a assez bien fonctionné.
Puis il y a eu une autre restructuration, autour de 2020. Nous avons encore réduit la taille de l'organisation, en nous rapprochant de 30 développeurs. Le plus gros changement touchait la façon dont les demandes arrivaient aux équipes. Le business trouvait que le processus était devenu trop complexe, alors le PMO a disparu et les unités d'affaires se sont rapprochées des équipes de développement. L'équipe plateforme a aussi disparu. Il restait deux équipes paysite et une équipe paiement, tout en continuant de porter les systèmes accumulés avec le temps. L'organisation était devenue plus petite et plus plate, mais la surface technique n'avait pas diminué avec elle.
C'était le décalage. L'architecture est restée distribuée. L'organisation, non.
Juste avant cette période, nous avions décidé d'aller plus sérieusement vers une architecture orientée services. Nous avions commencé à sortir des morceaux du monolithe vers des services, d'abord avec Slim, puis de plus en plus avec AWS, API Gateway et Lambda. À ce moment-là, la décision semblait raisonnable. Les services donnaient des surfaces de déploiement plus claires. Ils permettaient à différentes équipes de posséder différentes parties du système. Ils nous aidaient à séparer des responsabilités qui étaient entremêlées dans le monolithe. Pour la taille et l'ambition de l'organisation que nous avions alors, la direction avait du sens.
Mais après le changement d'organisation, cette même direction a créé un autre type de coût. Le rythme d'extraction a presque tombé à zéro. Les nouvelles fonctionnalités continuaient d'arriver, et chaque fois nous devions décider si nous allions construire dans le monde des services cloud ou dans l'ancien monolithe, parce qu'une partie de la capacité vivait encore là. Une équipe travaillait surtout avec les nouveaux services. Une autre était encore surtout dans le monolithe. Nous avons essayé de partager la connaissance plusieurs fois, mais une connaissance qui n'est pas utilisée ne reste pas fraîche. Les gens oubliaient ce qui avait été expliqué parce qu'ils ne travaillaient pas assez souvent dans ces systèmes, et cela créait de la frustration des deux côtés.
C'est là que j'ai commencé à voir la faille plus clairement. Ce n'était pas que les services étaient mauvais. C'est que notre stratégie de services supposait une forme d'équipe que nous n'avions plus. Les microservices ont besoin de propriétaires. Ils ont besoin de capacité opérationnelle. Ils ont besoin de gens qui comprennent les déploiements, l'observabilité, les mises à jour de runtime, les attentes de sécurité, la réponse aux incidents et le contexte d'affaires autour de chaque service. Quand l'équipe est assez grande, ce coût peut valoir la peine. Quand l'équipe devient plus petite, ce même coût devient une charge cognitive répartie sur moins de personnes.
Aujourd'hui, cette pression est encore plus claire. En 2026, l'organisation d'ingénierie est plus proche de 20 développeurs, et l'équipe paysite est beaucoup plus petite qu'avant. Le nombre de systèmes n'a pas diminué au même rythme. Certaines API sont maintenant legacy. Certaines doivent être mises à jour avant de pouvoir être redéployées de façon sûre. Nous devons encore livrer des fonctionnalités, mais nous portons aussi la facture de maintenance de chaque service créé quand l'organisation avait plus de capacité. Le travail n'est pas devenu moins important simplement parce qu'il reste moins de gens pour le faire.
Une grande partie du travail devient alors une forme de dégradation contrôlée. On ne peut pas tout redessiner. On stabilise ce qui doit rester vivant. On simplifie quand on touche déjà à une partie du système. On accepte que certaines pièces ne s'amélioreront pas ce trimestre, ou peut-être même cette année, parce que l'entreprise a encore besoin de livraison et que l'équipe a encore une quantité limitée d'attention. Ce n'est pas l'histoire d'architecture que les gens aiment raconter, mais c'est une histoire fréquente dans les systèmes qui durent.
Je ne pense pas que la bonne leçon soit de ne jamais sortir de morceaux du monolithe. Ce serait trop facile. Certains services étaient la bonne décision. Certaines frontières étaient réelles. Certaines parties du système ont profité d'un déploiement indépendant. La leçon est plutôt celle-ci : une frontière de service n'est pas seulement une frontière de code. C'est une promesse que l'organisation gardera assez d'ownership, d'attention et de maturité opérationnelle autour de cette frontière aussi longtemps que le service existera.
Si je pouvais rejouer la décision, je garderais probablement le monolithe plus longtemps et je rendrais ses frontières internes plus claires. Pas comme excuse pour tout garder emmêlé, mais comme un monolithe modulaire volontaire, avec des règles d'ownership plus fortes. Nous aurions pu définir quelles équipes possédaient quelles tranches verticales, qui pouvait changer les parties partagées, quand une décision plateforme devait être suivie, et comment le travail transversal devait être négocié. Cela n'aurait pas enlevé la complexité des parties prenantes, mais cela aurait peut-être réduit le coût d'une future réduction d'équipe.
J'ai fait un parallèle semblable après avoir écouté The Manager's Path. La structure qui fonctionne quand on a plusieurs équipes, des gestionnaires en ingénierie, des gestionnaires de gestionnaires, un directeur et un CTO n'est pas la même structure que celle qui fonctionne quand le groupe devient plus petit. Les couches de gestion ne sont pas automatiquement du gaspillage. À l'échelle, elles créent de l'alignement, développent les gens, gèrent la performance et empêchent les standards d'ingénierie de dériver. Mais quand l'organisation rétrécit, les mêmes couches et les mêmes frontières peuvent devenir trop lourdes pour la quantité de travail et de décisions qui restent.
Réduire la taille d'une organisation, ce n'est pas seulement enlever des boîtes d'un organigramme. Cela change l'architecture qu'on peut se permettre. Cela change le niveau de spécialisation qui est sain. Cela change si une équipe plateforme est un multiplicateur ou un luxe. Cela change si les équipes doivent posséder des services indépendamment ou partager un système plus clair et plus petit avec des conventions plus fortes. Nous planifions souvent la croissance parce que la croissance ressemble au cas de succès. Nous passons moins de temps à demander ce qui arrive si l'entreprise devient plus petite pendant que l'architecture garde la forme de l'entreprise plus grande.
Nous avons revu cette tension quand nous avons commencé à discuter d'une future structure avec une équipe d'enablement. Nous avions deux développeurs seniors avec une connaissance profonde du système, et l'idée était de les placer dans un rôle où ils pourraient partager cette connaissance entre les équipes au lieu de rester des points de défaillance uniques dans une seule équipe. Cette idée avait du sens pendant que nous pensions grossir de nouveau. En 2025, nous avons été acquis, et une autre équipe devait commencer à travailler avec nous. Pendant un temps, nous avons planifié la croissance. Au final, nous avons plutôt dû réduire.
Depuis quelques mois, je me demande si la montée de l'IA agentique change ce calcul. Si les services sont plus petits et mieux isolés, peut-être que l'IA peut travailler plus facilement avec eux. Un dépôt étroit, avec des tests clairs et un ownership clair, est plus facile à comprendre pour les humains comme pour les agents. Mais l'IA ne retire pas les coûts de topologie. Elle change l'endroit où ces coûts apparaissent. Si une petite équipe doit guider l'IA à travers trop de services, trop de flows de déploiement et trop de différences de runtime, la charge cognitive se déplace vers la planification, le prompting, la revue et la gouvernance du travail. L'IA peut écrire plus de code, mais quelqu'un doit encore comprendre assez bien le système pour décider si le résultat appartient là.
Je peux imaginer de plus petites équipes devenir plus efficaces avec l'IA. J'ai vu des gens décrire un modèle avec une personne côté affaires qui a une vraie opinion produit, deux bons développeurs et une bonne pipeline de livraison, et je peux voir comment cela pourrait fonctionner dans certains contextes. Je n'ai pas testé ce modèle moi-même, alors je le vois comme une possibilité plutôt qu'une conclusion. Mais cela pointe vers un vrai changement. La contrainte peut se déplacer du temps de saisie des développeurs vers le jugement produit, la qualité de revue, la discipline opérationnelle et la cohérence architecturale. Une équipe de six ou sept développeurs assistés par l'IA, capables de toucher au frontend, au backend et à l'infrastructure, peut produire beaucoup de changement. La question plus difficile est de savoir si l'entreprise a besoin d'autant de changement, et si le système peut l'absorber.
Si l'entreprise grossit de nouveau, je pense que les mêmes principes s'appliquent encore. Nous aurons besoin d'ownership clair. Nous aurons besoin de quelqu'un qui regarde les standards d'ingénierie entre les équipes. Nous aurons besoin de gestionnaires qui aident les développeurs à grandir et qui gardent les équipes alignées sur la façon de travailler. Nous devrons éviter que chaque équipe construise son propre workflow IA, ses propres standards et sa propre interprétation de la qualité. Plus les outils deviennent rapides, plus une direction partagée devient importante.
Le meilleur signal qu'il y a un problème n'est pas le mot monolithe ou microservices. C'est l'écart entre le système et les personnes disponibles pour le porter. On commence à voir plus de systèmes que de propriétaires. Un changement supposé rapide touche trois dépôts par défaut. Personne n'a le temps de simplifier quoi que ce soit. Une mise à jour de runtime donne l'impression de faire de l'archéologie parce que l'équipe qui a construit le service n'existe plus. Ce ne sont pas seulement des signaux techniques. Ce sont des signaux organisationnels qui apparaissent dans le code.
Au final, je pense que la structure d'équipe doit d'abord faire quelques choses. Elle doit répondre aux besoins de l'entreprise. Elle doit permettre au travail de passer de l'idée à la production sans trop de friction. Elle doit créer de l'accountability, pour que les équipes se sentent responsables de leur code et de leurs erreurs. Et elle doit être revue de temps en temps, parce que la base de code change, la technologie change, les besoins d'affaires changent, et le nombre de personnes disponibles pour porter le système change aussi.
Je resterais quand même prudent avec les changements d'équipe trop fréquents. Les relations comptent. La confiance compte. Parfois, changer ce qu'une équipe possède est mieux que de déplacer tout le monde dans une nouvelle structure qui semble plus propre sur papier, mais qui perd l'historique qui rendait l'équipe efficace. Les décisions d'architecture vieillissent. Les équipes changent. Les priorités bougent. Grandir n'est pas facile, mais c'est la version pour laquelle nous avons tendance à concevoir. Réduire l'échelle est la partie qu'on oublie de planifier, et c'est souvent là qu'on découvre quelles décisions l'organisation peut encore porter.
- Patrick