Comment réorganiser vos systèmes sans tout casser

L’architecture héritée et les structures d’équipe obsolètes entravent l’agilité.

Si la vitesse de votre équipe ralentit et que les tâches de base s’éternisent, il ne s’agit pas d’un problème de ressources, mais probablement d’un problème structurel. Chez Wattpad, après plus d’une décennie d’itérations sur le produit et l’infrastructure, des choses qui auraient dû être des gains rapides ont commencé à prendre trop de temps. Ce n’était pas subtil non plus. Les ingénieurs passaient plus de temps à déterminer où effectuer les changements qu’à les effectuer eux-mêmes.

Les architectures héritées font une chose très bien : elles restent en place. Si votre entreprise a commencé à construire il y a plus de 12 mois, et soyons honnêtes, c’est le cas de la plupart d’entre elles, il est probable que votre technologie comporte plus de couches qu’elle n’en a besoin. Ajoutez à cela une structure d’équipe qui n’a pas évolué avec la technologie, et vous obtenez un désalignement. C’est alors que l’agilité disparaît. Votre équipe produit cesse d’expédier rapidement. Les expériences s’enlisent. Les utilisateurs remarquent le retard ou vos concurrents prennent l’avantage.

Il ne s’agit pas d’un problème étrange. Il s’agit de croissance. Mais une croissance bien menée implique d’examiner attentivement si votre système actuel vous permet encore d’aller plus vite. La plupart des équipes évitent la remise à zéro. Cela semble risqué. Mais si vous voulez que vos collaborateurs se concentrent sur l’innovation plutôt que sur la maintenance, vous devrez faire évoluer la structure qui vous a permis d’arriver jusqu’ici. Et bientôt.

L’héritage n’est pas seulement synonyme de vieux code, mais aussi d’inertie institutionnelle. Pour les dirigeants, c’est le signal qu’il faut aller au-delà des mises à jour incrémentales. Il s’agit d’une stratégie, pas d’un nettoyage. Remettre à plus tard les changements architecturaux parce qu’ils sont politiquement ou opérationnellement gênants ? C’est une réflexion à court terme. Vous devez concevoir pour aujourd’hui et pour demain, même si cela implique de bouleverser quelques flux de travail sacrés.

Une complexité accrue et des équipes full-stack cloisonnées augmentent la charge cognitive.

Wattpad a adopté une approche que de nombreuses entreprises privilégient : des équipes complètes et alignées sur le produit. Sur le papier, cela fonctionne. Les équipes s’approprient l’expérience de bout en bout et peuvent agir rapidement. En pratique, les choses ont changé. La plateforme s’est développée, ce qui semble être une bonne chose. Mais la complexité s’est accrue avec elle.

Soudain, chaque équipe avait besoin de comprendre trop de choses : des systèmes qu’elle n’avait pas construits, des flux de travail hérités qu’elle n’avait pas conçus et des surfaces qui augmentaient de façon exponentielle. Ce n’est pas de l’autonomie efficace, c’est de la surcharge. Lorsque tout le monde possède tout, personne ne possède rien. Le résultat ? Le conflit. Les gens tirent le système dans des directions différentes en fonction de leurs priorités locales, ce qui crée des frictions. Non pas parce qu’ils ont tort, mais parce qu’ils ne peuvent plus avoir une vue d’ensemble.

Cela a également augmenté la charge cognitive. Les ingénieurs ont passé du temps à comprendre ce qu’il fallait changer avant même de commencer à coder. Et lorsque la coordination échoue, même les conceptions bien intentionnées commencent à diverger. Une équipe prend une décision intelligente qui brise le pipeline d’une autre. Non pas parce que quelqu’un s’est trompé, mais parce que personne ne savait à quel point le trou de lapin était profond.

Du point de vue de la direction, il ne s’agit pas d’un problème d’outillage. Il s’agit d’un problème structurel. Les équipes interfonctionnelles ne s’adaptent pas linéairement à la complexité du produit ou de la technique. Si vous n’ajoutez pas de limites et de clarté à la croissance, vous vous retrouvez avec des rôles qui se chevauchent et qui sont inefficaces. Cela conduit à l’épuisement, aux bogues et aux bloqueurs. Au lieu de cela, concevez une propriété prévisible et réduisez l’exposition inutile au système. Faites évoluer votre organisation comme vous faites évoluer votre plateforme, intentionnellement.

Le manque de temps consacré à l’investissement technique aggrave les difficultés existantes

La plupart des entreprises ne sont pas à la traîne parce qu’elles manquent d’idées ou de talents. Elles prennent du retard parce qu’elles ne donnent pas la priorité à la santé du système. Chez Wattpad, les demandes d’initiatives de nouveaux produits ont consommé la quasi-totalité du temps et de l’attention disponibles. Conséquence ? Il ne restait plus d’espace pour les mises à niveau de l’infrastructure ou la réduction de la dette technique. Chaque lancement de fonctionnalité a commencé à sembler plus lourd, plus lent et plus incertain.

Il ne s’agit pas d’un échec technique. Il s’agissait d’un manque d’équilibre. Lorsque les équipes s’enlisent dans le poids de systèmes fragiles et de modèles obsolètes, elles avancent avec prudence, même lorsque la rapidité est nécessaire. Les équipes de produits donneront toujours la priorité à ce qui apporte de la valeur rapidement. C’est une bonne chose. Mais lorsque les dirigeants ne font pas de place aux améliorations fondamentales, le système se dégrade lentement.

Plus l’investissement technique est différé, plus il devient coûteux. Les ingénieurs finissent par passer leur temps à soutenir l’insoutenable, à plonger la tête la première dans des environnements hérités qu’ils n’ont jamais touchés, à reconstruire les mêmes abstractions à plusieurs reprises et à perdre leur élan. Pendant ce temps, le coût d’opportunité s’alourdit.

Pour les dirigeants, la conclusion est simple. Votre feuille de route doit réserver de l’espace pour moderniser à la même cadence que vous innovez. Si le travail technique est toujours reporté au profit des fonctionnalités, vous ne faites qu’augmenter les frictions et les coûts futurs. Tous les dirigeants qui supervisent les produits ou l’ingénierie devraient pouvoir répondre à cette question : quelle part du temps de votre équipe est réservée à la santé à long terme du système ? Si la réponse est « pas assez », vous travaillez activement contre votre propre trajectoire de croissance.

Le décalage entre la structure organisationnelle et l’architecture des systèmes nécessite une refonte intentionnelle.

Il existe un principe que vous devriez connaître, la loi de Conway. Les équipes d’ingénieurs s’y réfèrent depuis des années parce qu’elle tient la route. En termes simples, la façon dont vous structurez vos équipes influe sur le comportement de vos systèmes. Wattpad s’est rendu compte que ses équipes avaient évolué d’une manière qui ne correspondait plus à l’architecture sur laquelle elles s’appuyaient. Ce décalage a commencé à nuire à la clarté technique, à la cohérence du système et aux résultats de l’équipe.

Lorsque la structure de votre organisation diverge de la manière dont le travail est réellement effectué, les frictions augmentent. Les équipes ne font pas que ralentir, elles multiplient la complexité. Chez Wattpad, le chevauchement des propriétaires se traduisait par des chemins redondants dans l’évolution du système. Aucun fil conducteur n’assurait la cohésion du système. Des ingénieurs intelligents faisaient des choix judicieux, mais sans ancrage organisationnel, ils ne pouvaient pas étendre ces choix à d’autres produits ou plateformes.

Pour y remédier, Wattpad ne s’est pas contenté de changer de technologie. Elle a également revu son modèle organisationnel. Ils ont défini des limites claires pour les systèmes et ont aligné les équipes sur chacune d’entre elles. Les dirigeants ont travaillé en étroite collaboration avec les ingénieurs pour ancrer la transformation dans la manière dont la plateforme fonctionne aujourd’hui et dont elle doit évoluer au cours de la prochaine étape.

La plupart des transformations échouent non pas parce que la stratégie est mauvaise, mais parce que les structures de communication et d’incitation ne correspondent pas aux objectifs techniques. Pour les dirigeants, il est essentiel de comprendre que l’architecture n’est pas une décision d’arrière-plan, mais qu’elle dépend directement de la manière dont vos équipes sont dotées en personnel, structurées et encouragées à collaborer. Si vous voulez des systèmes évolutifs, commencez par des structures évolutives. Ensuite, redessinez les deux.

La refonte itérative fondée sur les connaissances des ingénieurs favorise les changements évolutifs.

Wattpad n’a pas traité sa refonte de l’architecture comme un mandat descendant. Au contraire, elle a fait appel aux personnes les plus proches des systèmes, les ingénieurs qui vivent les problèmes au quotidien. Les responsables techniques et les ingénieurs de première ligne ont procédé à des examens approfondis des systèmes et à des diagnostics continus. Ces connaissances ont servi de base aux changements architecturaux et organisationnels. L’apport du monde réel a permis de mieux ancrer les choses, de les rendre plus flexibles et d’augmenter les chances de réussite.

Les ingénieurs ont pu choisir et s’approprier le projet. Ils ont opté pour des domaines spécifiques de la plateforme en fonction de leur contribution. La direction a apporté son soutien et sa vision, mais l’exécution a été répartie. Il ne s’agissait pas de dicter ce qu’il fallait réparer, mais d’éliminer les obstacles afin que les ingénieurs puissent faire des progrès significatifs sur ce qu’ils savaient déjà nécessiter une attention particulière.

Cette approche n’a pas abouti à un état final parfait, mais à une dynamique. Les systèmes ont commencé à évoluer dans la bonne direction. Les ingénieurs ne réagissaient plus aux pannes ou aux correctifs apportés aux problèmes hérités du passé ; ils concevaient des projets d’avenir, avec des limites architecturales solides qui leur permettaient de travailler de manière plus indépendante et plus efficace.

Pour les dirigeants, la clé réside dans la responsabilisation, soutenue par le contexte. Les ingénieurs savent où se situent les points douloureux bien plus tôt que les dirigeants. Votre rôle n’est pas de prescrire la solution. Il consiste à vous assurer qu’ils disposent du temps, de l’autonomie et des informations nécessaires pour résoudre les problèmes réels au niveau du système. La stratégie ne réussit pas tant qu’elle n’atteint pas les mains qui conçoivent et déploient le travail. Les organisations les plus performantes sont celles où la prise de décision est aussi intelligente que l’infrastructure.

La transformation continue de l’organisation exige de la flexibilité

La transformation de Wattpad ne s’est pas faite de manière isolée. Il s’agissait d’un changement coordonné entre les systèmes, les équipes et les perspectives de leadership. Les changements d’architecture ont été reflétés par des changements dans la structure de l’équipe, les priorités et la façon dont les décisions ont été prises. Certains systèmes ont été reconstruits. D’autres ont été progressivement abandonnés. L’organisation s’est adaptée, étape par étape, sans compromettre les résultats essentiels. Ce type de progrès à deux voies exige de la clarté, de la discipline et l’adhésion de toutes les fonctions.

La confiance a été un facteur clé de réussite. Les responsables de l’ingénierie n’ont pas imposé le changement de haut en bas. Au contraire, ils ont invité à la collaboration. Les ingénieurs ont élaboré des solutions. Les managers ont débloqué des voies. Les dirigeants sont restés alignés sur la vision à long terme tout en acceptant que la structure actuelle soit transitoire. Ce mélange de confiance et d’agilité a permis de garantir que, même lorsque chaque système n’était pas parfait, les équipes disposaient d’une orientation et d’une dynamique claires. Surtout, personne n’a perdu de vue l’objectif réel : permettre un développement plus rapide des produits en rétablissant la clarté technique.

Ils sont toujours en évolution. L’architecture et la structure ne sont pas figées. Elles sont conçues pour s’adapter. Ce qui importe, c’est que l’organisation dispose désormais d’un processus de changement, qui ne s’appuie pas sur des solutions d’urgence ou de longs délais. C’est ainsi que la capacité devient la norme et non l’exception.

Pour les dirigeants, il ne s’agit pas seulement d’une question d’ingénierie. La résilience organisationnelle commence par une prise de décision harmonisée et une feuille de route commune à toutes les fonctions. La transformation n’attend pas un plan final ; elle commence par une structure qui invite au retour d’information, absorbe les leçons et maintient le mouvement vers l’avant. Si vos équipes ne se sentent pas en confiance et si la direction n’est pas disposée à évoluer avec la réalité, vous n’êtes pas en train de vous transformer, vous êtes en train de piétiner.

Principaux enseignements pour les décideurs

• Donnez la priorité aux audits d’architecture au fur et à mesure que les systèmes arrivent à maturité : L’architecture héritée et les structures d’équipe de départ se dégradent au fil du temps, ce qui ralentit l’exécution et réduit l’agilité du produit. Les dirigeants devraient réévaluer les bases techniques dès le début pour maintenir la vitesse à l’échelle.
• Réduisez l’exposition au système pour diminuer la charge cognitive de l’équipe : Les équipes full-stack surchargées sont confrontées à une complexité qui fragmente la propriété et ralentit la livraison. Les dirigeants devraient simplifier l’accès à la technologie en délimitant clairement les domaines de responsabilité et de système.
• Allouez du temps protégé à l’investissement technique : Lorsque les correctifs de l’infrastructure sont perpétuellement mis au second plan, la dette technique s’alourdit et l’innovation s’enlise. Les dirigeants doivent faire de la place dans les feuilles de route pour la santé à long terme du système, et pas seulement pour les caractéristiques du produit.
• Aligner les équipes sur le fonctionnement réel des systèmes : Les structures de communication déconnectées et l’architecture des systèmes sont source d’inefficacité. Redéfinissez les organisations en fonction des limites des systèmes afin de garantir la collaboration, l’appropriation et l’évolutivité de la plateforme.
• Élever les ingénieurs au rang de partenaires de la transformation : Les changements imposés d’en haut limitent l’efficacité. Donner aux ingénieurs les moyens de diriger la refonte des systèmes permet d’obtenir des améliorations fondées et évolutives, ancrées dans l’utilisation du monde réel et la compréhension au niveau de l’équipe.
• Traitez la transformation comme un modèle opérationnel permanent : Un changement durable exige de la flexibilité, une confiance interfonctionnelle et une itération constante. Les dirigeants doivent aligner leur vision sur l’évolution des structures de l’équipe afin de maintenir l’agilité et l’élan.