Les frictions sont le principal obstacle aux systèmes logiciels
Vous pensez peut-être que vos plus grands défis en matière de logiciels sont d’ordre technique, qu’il s’agit d’architecture cloud, d’outils de déploiement ou de frameworks. Ce n’est pas le problème. Le vrai problème, c’est la friction. Non pas la friction entre les machines, mais entre les personnes. Les ruptures de communication. Des priorités mal alignées. Des incitations contradictoires. Tels sont les facteurs qui érodent discrètement l’exécution et font dérailler la transformation.
Ce type de friction est systémique. Il est présent dans vos organigrammes, vos processus, vos modèles mentaux. Les équipes techniques et les équipes de produits se rejettent mutuellement la responsabilité des échecs, tandis que les grandes initiatives progressent avec des tableaux de bord impressionnants, jusqu’à ce qu’elles ne le fassent plus. Le projet s’effondre, vous effectuez une rétrospective, puis vous recommencez. Ce cycle ne s’arrête pas tant que les frictions ne sont pas traitées à la racine.
Ce qu’il faut, c’est changer le mode de pensée et de fonctionnement de vos équipes. Cela inclut la manière dont les informations circulent, dont les décisions sont prises et dont les problèmes sont définis. Vous ne pouvez pas résoudre les risques d’exécution ou les problèmes de livraison en imposant davantage de fonctionnalités. Vous les résoudrez en réduisant les freins créés par la mauvaise communication, le désalignement et les incitations structurelles obsolètes.
Cat Morris, chef de produit, et Diana Montalion, architecte système, ont exploré ce problème par expérience directe. Elles ont apporté des perspectives opposées et ont découvert que le problème n’était pas l’une ou l’autre. Le problème était le système dans lequel elles essayaient de naviguer. Leurs rôles se chevauchaient de manière inattendue. En s’unissant, ils ont aligné les résultats et éliminé les gaspillages. C’est une leçon pour tous les dirigeants technologiques : l’ennemi ne se trouve pas dans l’organigramme, mais dans vos modes de fonctionnement. Il se trouve dans vos modes de fonctionnement.
Un comportement contre-intuitif fait dérailler le progrès
Lorsque les projets dérapent, les équipes réagissent rapidement. Elles ajoutent des ingénieurs, prolongent les délais et renforcent la surveillance. Cela ressemble à de l’action, mais cela aggrave souvent le problème. C’est ce que l’expert en systèmes Jay Forrester a décrit comme un « comportement contre-intuitif ». La solution semble évidente, mais elle intensifie le problème réel.
Cela se produit lorsque les délais techniques ne sont pas respectés. L’hypothèse par défaut ? L’équipe n’est pas assez performante. Ou le calendrier était trop ambitieux. Mais le vrai problème pourrait être que le système produit exactement le résultat pour lequel il a été conçu. W. Edwards Deming l’a dit clairement : « Chaque système est parfaitement conçu pour obtenir le résultat qu’il obtient ».
C’est le piège. Les dirigeants réagissent en fonction des symptômes. Ils s’arrêtent rarement pour examiner si la structure elle-même est à l’origine de l’échec. Si le plan repose sur des hypothèses erronées ou des modèles incompatibles, par exemple en imposant un modèle de prestation linéaire à un système non linéaire, l’urgence n’y changera rien.
Voici donc la marche à suivre : prenez du recul. Alignez tout le monde sur la mission actuelle, appelez-la votre étoile polaire. Pour FedEx, ce serait la vitesse de livraison. Dans le secteur des technologies, il s’agit peut-être de la fiabilité des déploiements ou de la réduction des frictions avec les clients. Déterminez ensuite comment votre système actuel ne permet pas d’atteindre cet objectif. Examinez comment les décisions sont prises, comment les équipes sont connectées et comment les progrès sont mesurés. Les données circulent-elles en temps réel ? Des boucles de rétroaction sont-elles en place ? Les gens résolvent-ils le bon problème ?
Si ce n’est pas le cas, vous avez des bloqueurs invisibles qui orchestrent un échec visible. Et vous ne pouvez pas faire mieux que l’ingénierie. Vous avez besoin d’une pensée plus claire, d’une meilleure structure et de systèmes qui renforcent les résultats, et non des cycles d’efforts mal diagnostiqués. C’est ainsi que vous cesserez de réagir et que vous commencerez à réparer.
La résistance au changement découle de l’inertie culturelle
Dans presque toutes les entreprises qui essaient de s’améliorer, il y a quelqu’un qui ralentit les choses. Cette personne est expérimentée, connaît les systèmes existants sur le bout des doigts et détient les clés de l’infrastructure critique. Ils ont vu les efforts de re-platforming échouer. Ils ont survécu à de multiples réorganisations. Ils disent donc non aux nouvelles approches, aux nouveaux outils, à la nouvelle façon de penser. Il est facile de les montrer du doigt et de les qualifier de résistants. Mais ils ne font que réagir au système qui leur a donné les moyens d’agir.
Leur résistance a été récompensée. Ces personnes deviennent indispensables non pas parce qu’elles soutiennent l’innovation, mais parce qu’elles gèrent la complexité. Lorsque votre organisation définit sa valeur en fonction de ceux qui peuvent « faire tourner les choses » et non de ceux qui peuvent améliorer les systèmes, vous finissez par protéger le statu quo. Il en résulte un état d’esprit qui favorise la prudence au détriment de la curiosité, et vous cessez d’entendre de nouvelles idées parce que les personnes qui en sont porteuses cessent de s’en préoccuper.
Le plus dangereux ? Cet état d’esprit se répand. Un gardien crée une dynamique silencieuse : les autres commencent à éviter l’incertitude. Des équipes entières passent de la question « Qu’est-ce qui pourrait marcher ? » à la question « Pourquoi essayer ? ». Lorsque les vieux schémas dominent, la transformation s’arrête, non pas parce qu’il n’y avait pas de stratégie, mais parce que le système a bloqué les personnes qui voulaient la mettre en œuvre.
John Belasco et Ralph Stayer ont écrit à ce sujet dans leur livre Flight of the Buffalo. Ils l’ont exprimé sans détour : « Le changement est difficile parce que les gens surestiment la valeur de ce qu’ils ont et sous-estiment ce qu’ils pourraient gagner en y renonçant. Il s’agit là d’un obstacle psychologique, pas d’un obstacle technique. C’est un obstacle psychologique, pas un obstacle technique, qui doit être traité au niveau du système, et pas seulement corrigé au niveau individuel.
Si vous conduisez le changement, ne perdez pas de temps à convaincre les bloqueurs de bouger. Donnez-leur un espace où ils peuvent maintenir la stabilité sans contrôler la transformation. Ensuite, déplacez l’énergie vers les équipes qui sont prêtes à bouger. Laissez-les montrer des résultats. Le changement est rarement convaincant en théorie. Il est prouvé par l’élan.
L’efficacité et le contrôle peuvent nuire à la valeur réelle
La plupart des organisations considèrent par défaut l’efficacité comme l’étoile polaire. Elle rend les choses prévisibles. Vous comptez les fonctionnalités livrées. Vous suivez les points d’histoire clôturés. Vous tenez les équipes au courant des échéances. Vous avez l’impression de progresser. Mais ce qui se perd souvent dans ce processus, c’est la valeur réelle.
Lorsque le travail devient axé sur les résultats, sur les mesures de productivitévous finissez par optimiser le mouvement. Les équipes sont soumises à des pressions pour respecter les délais, sans se demander si le travail permet de résoudre quelque chose d’important. Vous construisez donc rapidement, mais ce que vous livrez n’a pas forcément d’importance pour les clients ou pour l’entreprise. Ce décalage est à l’origine de l’inefficacité à long terme, même si vos indicateurs à court terme semblent bons.
Le contrôle y contribue également. Plus vous essayez de contrôler étroitement les livraisons, plus vous limitez le flux d’informations importantes entre les équipes. Les questions ne sont pas posées. Les compromis ne sont pas mis en évidence. Le retour d’information arrive trop tard. Vous confondez alignement et silence. Et lorsque la complexité réelle apparaît, le système n’est pas flexible. Il ne peut pas s’adapter.
Au niveau du système, ce que vous voulez, c’est de la cohérence, et pas seulement du contrôle. Vous voulez que les bonnes données parviennent aux bonnes personnes, au bon moment, avec clarté, afin que les équipes puissent agir intelligemment, et pas seulement rapidement. Cela signifie qu’il faut repenser les outils que vous utilisez pour mesurer les progrès. Demandez-vous si vos équipes s’efforcent d’obtenir des résultats ou si elles se contentent de mettre à jour les tableaux de bord.
Si votre feuille de route est bloquée et que vos délais ne reflètent pas la réalité, prenez du recul. Optimisez la circulation des connaissances entre les disciplines et les modèles mentaux. C’est ce qui accélère réellement l’obtention de résultats significatifs. Lorsque vous comprenez comment le travail contribue aux objectifs de l’entreprise, vous perdez moins de temps et vous apportez plus de valeur réelle.
Les silos de produits et de technologies aggravent les frictions
Il s’agit d’un schéma courant : les équipes de produits veulent que les nouvelles fonctionnalités soient livrées rapidement, et les équipes d’ingénieurs ont l’impression qu’on leur demande de livrer un code de mauvaise qualité à la hâte. Aucune des deux parties n’a tort en soi. Ils sont simplement soumis à des pressions et à des définitions différentes de ce qu’est le progrès. Cette tension, lorsqu’elle n’est pas gérée, devient l’un de vos principaux goulets d’étranglement.
Les équipes de produits sont responsables des résultats pour les clients. Elles respectent les délais et donnent la priorité à l’impact sur les utilisateurs. Les équipes d’ingénieurs sont responsables de l’intégrité du système. Elles repoussent les codes fragiles, dette techniqueet une mauvaise architecture. Lorsque ces deux rôles fonctionnent de manière isolée, la collaboration se transforme en blâme. Vous n’obtenez pas d’alignement. Vous obtenez des arguments sur la portée, la faisabilité et la raison pour laquelle quelque chose a pris plus de temps que prévu.
Le plus gros problème n’est pas le désaccord, mais le fait que les deux équipes sont bloquées dans un état d’esprit fixe. Elles partent du principe que l’autre partie ne comprend pas, et cessent donc d’essayer d’établir une compréhension mutuelle. Pas d’objectifs communs. Pas de réussite commune. Cela crée des équipes fragiles, où l’apprentissage est remplacé par la défense du territoire.
La voie à suivre n’est pas de multiplier les processus. Il s’agit d’adopter ce que Carol Dweck appelle un état d’esprit de croissance, dans tous les rôles et toutes les équipes. Cela signifie qu’il faut se concentrer sur les problèmes à résoudre, et pas seulement sur les tâches à accomplir. Cela signifie qu’il faut interpréter les réactions négatives comme un contexte et non comme un conflit. Cela signifie qu’il faut encourager les équipes à réfléchir à ce qui fonctionne et à corriger le tir sans blâmer qui que ce soit.
Lorsque les gens comprennent les objectifs de chacun, ils cessent de considérer la collaboration comme un compromis. Le produit apprend à apprécier la santé technique à long terme. L’ingénierie relie son travail à la valeur commerciale à court terme. C’est là le changement. Il ne s’agit pas seulement de s’entendre, mais de penser ensemble. C’est là que commence la résilience.
La pensée linéaire en pipeline échoue dans un monde asynchrone
De nombreux cadres de livraison partent du principe que le travail s’effectue en ligne droite. Planifier, concevoir, construire, tester, lancer. Mais dans les systèmes actuels, où les équipes s’appuient sur des services distribués, des API et des microservices, très peu de choses se déroulent en ligne droite. Le travail n’est pas séquentiel. Il est interconnecté, axé sur les événements et asynchrone.
Voici ce que cela signifie en pratique : souvent, les problèmes ne proviennent pas d’un seul composant, mais de l’interaction entre les composants. C’est pourquoi le débogage devient plus difficile. Le système se comporte désormais en fonction de ses relations, et non plus seulement de ses parties. Ainsi, lorsque les modèles de livraison sont construits sur des cadres purement linéaires, ils excluent la complexité même qu’ils doivent gérer.
Vous ne pouvez pas modéliser efficacement les systèmes modernes sans inclure la synthèse, en rassemblant des perspectives multiples à travers les rôles, les équipes et les plateformes. Les architectes, les développeurs, l’infrastructure, la sécurité et le produit doivent collaborer pour comprendre comment les différentes parties du système influencent les performances, la fiabilité et l’expérience de l’utilisateur. Il ne s’agit pas de préoccupations isolées. Il s’agit de responsabilités communes.
Cette évolution oblige les équipes à penser en termes de relations, de communication entre les services, de circulation des données et de répercussion des changements dans le système. Si vous ignorez ces dépendances, les problèmes restent cachés jusqu’à ce qu’ils atteignent la production. À ce stade, le coût de la correction est élevé.
Les dirigeants doivent soutenir la conception de systèmes, pas seulement de logiciels, mais de systèmes organisationnels, où l’information circule clairement entre les équipes. La vision interfonctionnelle doit faire partie du processus de développement. Si votre modèle opérationnel cloisonne les responsabilités, votre architecture reproduira ce cloisonnement dans le code. Il en résulte une livraison fragile, une reprise lente en cas d’incident et une adaptabilité limitée.
N’optimisez pas l’illusion de la linéarité. Optimisez pour des relations claires. C’est ainsi que vous arrêterez les problèmes de livraison avant qu’ils ne prennent de l’ampleur.
Les échecs de livraison sont dus au fait que l’on se concentre sur les outils plutôt que sur les objectifs.
Les équipes se voient souvent confier une tâche, migrer vers une nouvelle plateforme, remplacer un outil existant, mettre en œuvre un système prêt à l’emploi. Mais on leur explique rarement pourquoi. Sans objectif clair, elles suivent les instructions, cochent la case et passent à autre chose. Que le travail améliore ou non quoi que ce soit n’a plus d’importance, car les résultats n’ont pas été définis dès le départ.
C’est l’une des principales raisons de l’échec des livraisons. Lorsque l’exécution est axée sur l’activité plutôt que sur l’intention, votre organisation commence à optimiser l’achèvement du projet plutôt que la valeur commerciale. Une équipe peut exécuter toutes les tâches prévues, mais le résultat n’améliore pas les performances du système ou la satisfaction des utilisateurs. Du temps et de l’argent sont dépensés, mais les capacités restent inchangées.
Pour y remédier, vous devez clarifier l’objectif avant même de commencer le travail. Un objectif n’est pas une tâche. Il s’agit d’un résultat mesurable lié aux priorités fondamentales de l’entreprise. Par exemple, si vous dites que vous voulez passer de Jenkins à CircleCI, il s’agit d’une tâche. Mais si votre objectif réel est de réduire le travail des développeurs, la migration n’est qu’une option parmi d’autres. Les équipes peuvent trouver de meilleures alternatives, moins coûteuses, plus efficaces, si elles comprennent le résultat final que vous visez.
L’exécution axée sur les résultats permet également d’éviter les désalignements entre les parties prenantes. Lorsque les ingénieurs, les équipes de produits et les dirigeants savent quel est l’impact de leur travail, ils prennent de meilleures décisions. Ils établissent des priorités en fonction de la contribution à cet impact, et pas seulement de l’achèvement de l’effort assigné. Il en résulte des itérations plus rapides, des solutions plus pertinentes et des systèmes qui évoluent vers des objectifs commerciaux au lieu de se contenter de moderniser l’infrastructure pour le plaisir.
Votre rôle en tant que dirigeant est de veiller à ce que l’objectif soit visible, précis et directement lié à des rendements significatifs. Lorsque c’est le cas, vos équipes ne se contentent plus d’exécuter le travail, elles commencent à générer de la valeur.
L’expérimentation à petite échelle et intentionnelle permet une amélioration systémique
La complexité des systèmes modernes peut être accablante, surtout lorsque des frictions apparaissent partout, de la coordination à la technologie en passant par les ruptures de livraison. Il est tentant d’envisager une refonte, de tout réaligner d’un seul coup. Cette approche est rarement efficace. Il est préférable de procéder à des expérimentations plus modestes et intentionnelles.
On n’améliore pas un système en remplaçant chaque pièce. Vous l’améliorez en apportant des changements réfléchis, en observant les résultats et en procédant à des ajustements en temps réel. Ces expériences n’ont pas besoin d’être massives. Elles doivent être suffisamment spécifiques pour révéler où se situent les frictions et comment vos équipes réagissent lorsque ces frictions sont supprimées. Cela vous permet d’y voir plus clair sans risquer de perturbations inutiles.
Cette approche respecte également les capacités limitées. Les équipes sont déjà sous pression. Vous n’avez pas besoin d’ajouter du chaos. Vous devez les aider à se concentrer sur une contrainte, une inefficacité, un modèle qui ne fonctionne pas. Lorsque cela change, le retour d’information permet d’éclairer des décisions plus larges. L’élan se crée naturellement, pas artificiellement.
En tant que responsable, votre tâche consiste à autoriser et à soutenir ce type de changement. Laissez une équipe remettre en question un processus de transfert. Laissez un chef de produit redéfinir les critères de réussite pour le déploiement d’une fonctionnalité. Laissez un architecte introduire un meilleur flux de connaissances entre les fonctions. Commencez à petite échelle. Mesurez l’impact. Partagez les résultats.
C’est ainsi que la transformation des systèmes se fait, lorsque les équipes sont habilitées à réfléchir, à s’adapter et à apporter des améliorations sur la base de ce qu’elles voient au quotidien. Chaque friction éliminée s’amplifie au fil du temps. Vous n’avez pas besoin de mandats venant d’en haut. Vous avez besoin de personnes intelligentes et engagées qui se concentrent sur la résolution des problèmes qu’elles sont les mieux placées pour comprendre. La stratégie consiste à leur donner les moyens d’agir.
Récapitulation
Si vous dirigez une entreprise qui construit des logiciels, prenez un peu de recul et demandez-vous où se trouvent les véritables obstacles. Il y a de fortes chances qu’ils ne se trouvent pas dans vos outils. Ils se trouvent dans la façon dont vos équipes communiquent, dont les rôles sont structurés et dont les décisions sont prises. Il ne s’agit pas de défauts, mais de signaux. Ils vous indiquent les points sur lesquels vous devez vous concentrer si vous voulez des systèmes plus solides et des résultats plus rapides.
Les frictions surviennent lorsque les systèmes ne sont pas alignés sur la façon dont les gens travaillent réellement. Pour y remédier, il ne faut pas tout démolir. Il s’agit d’éliminer les obstacles qui ralentissent vos équipes. Il s’agit de structurer le travail autour d’objectifs communs plutôt que de résultats isolés. Cela signifie créer un espace pour l’apprentissage, la synthèse et une exécution plus intelligente.
Votre avantage ne réside pas dans le fait de disposer de la plateforme la plus récente ou de l’effectif le plus important. Il réside dans l’efficacité avec laquelle votre organisation s’adapte à la complexité, dans la rapidité avec laquelle vos collaborateurs peuvent prendre les bonnes décisions, apporter des changements significatifs et évoluer en fonction des besoins du système.
Vous n’avez pas besoin de contrôler chaque détail. Vous devez créer les conditions nécessaires pour que les bonnes choses se produisent sans que vous ayez à les gérer. C’est ainsi que l’on passe à l’échelle supérieure. C’est ainsi que vous obtiendrez de la vitesse sans chaos. Si vous supprimez les frictions, le progrès cesse d’être difficile. Il devient simplement la prochaine chose qui se produit.
