.svg)
La série d'entretiens Strategy Pattern révèle comment les leaders technologiques prennent des décisions critiques dans des environnements complexes et changeants. S'appuyant sur des exemples concrets et des cadres reproductibles, il fournit des informations exploitables pour anticiper les défis et guider les organisations en toute confiance. Vous pouvez en savoir plus et voir d'autres interviews dans la série ici.
David Linten, directeur technique de TrustPortal, a fait face à un défi auquel tous les leaders technologiques sont finalement confrontés. Son équipe s'était associée à EY, remportant le contrat Telefónica, pour diriger ce qui était, à l'époque, l'un des plus grands déploiements d'automatisation des processus robotiques au monde. Ils ne disposaient pas encore d'une approche systématique des défaillances structurelles qui commenceraient à s'accumuler presque immédiatement après le début des travaux.
Les chronologies des sprints ont refusé de se synchroniser. Le champ d'application a évolué au fur et à mesure que le client contournait les problèmes au lieu de les résoudre. Des personnes clés sont parties et ont emporté avec elles des connaissances essentielles. Le logiciel de robotique a ensuite publié une mise à jour qui a interrompu tous les processus automatisés mis en place par l'équipe, et les connaissances nécessaires pour y remédier se trouvaient au sein d'une organisation partenaire dont la méthode de travail était incompatible. Chaque point de contrôle était un engagement contractuel que Telefónica avait déjà pris envers ses propres clients. Le fait d'en manquer un n'était pas un inconvénient pour la livraison. Ce fut un échec commercial en cascade.
L'expérience de Linten mérite d'être examinée, ce n'est pas parce qu'il a dispensé le programme. C'est parce que le chemin était peu structuré, coûteux et interrompu à plusieurs reprises avant qu'une approche systématique n'apparaisse. Voici un compte rendu de ce voyage et du cadre qu'il a construit à partir de celui-ci.
TrustPortal a été fondée en 2017 par Chris Lamberton et deux autres personnes, et Chris est désormais conseiller stratégique. David Linten a rejoint l'équipe en tant que directeur technique, apportant une formation passée de la physique au génie logiciel.
La proposition principale de TrustPortal a évolué, passant de l'intégration de l'automatisation robotique des processus (RPA) à ce que l'entreprise décrit aujourd'hui comme une hyperautomatisation agentique en temps réel : orchestrer simultanément des humains, des agents d'IA et des systèmes existants pour fournir des flux de travail complexes en quelques secondes, sans remplacer l'infrastructure existante. Sa plateforme est reconnue dans les secteurs de la banque, de l'assurance, des services publics et des télécommunications, avec des clients tels que Telefónica, EDF, IBM, OVO Energy et d'autres.
L'un de ses déploiements phares reste la transformation des centres de contact, où la plateforme de TrustPortal propose une « interface utilisateur générative » en temps réel qui crée des flux de travail guidés pour les conseillers, élimine les sauts de système, réduit les ressaisies et affiche les résultats lors de l'appel plutôt que dans une file d'attente de suivi.
La société travaille sur l'ensemble de la chaîne de distribution, des systèmes bancaires dorsaux aux interfaces client frontales, et a établi un partenariat de livraison durable avec Imaginary Cloud qui s'étend sur plus de onze ans.
Depuis le début, la philosophie de Linten était la suivante : il ne travaille pas avec des développeurs, il préfère les appeler ingénieurs, et cette distinction est importante pour lui. Un développeur écrit du code. Un ingénieur comprend l'architecture. « Nous n'embauchons pas de développeurs », déclare-t-il. « Nous recrutons des ingénieurs. Tout le monde joue un rôle dans l'architecture, jusqu'à l'écriture de lignes de code. »
Cette philosophie a influencé toutes les décisions qu'il a prises dans le cadre du programme Telefónica, y compris celles qu'il aurait aimé prendre plus tôt.
L'engagement avec Telefónica a fait entrer TrustPortal dans une chaîne de distribution aux côtés d'EY en tant qu'intégrateur de systèmes et de Blue Prism en tant que fournisseur de logiciels de robotique. L'appel d'offres avait opposé TrustPortal et EY directement à 10 autres intégrateurs de systèmes. TrustPortal a gagné, en grande partie parce que son équipe d'ingénieurs a pu agir plus rapidement et avec moins d'erreurs qu'une grande organisation qui s'appuie sur des départements séparés et des boucles de feedback plus lentes.
Ce que personne n'a dit à l'époque, c'est que l'obtention d'un contrat en étant petit, rapide et rigoureux sur le plan architectural ne vous protège pas de ce qui se passe ensuite lorsque vous opérez dans une structure qui n'est rien de tout cela.
Le programme était structuré autour de cycles de points de contrôle de trois mois, chacun constituant un engagement commercial ferme déjà pris envers les clients B2B de Telefónica. Les problèmes sont apparus presque immédiatement.
Les chronologies de sprint entre les partenaires ne sont jamais naturellement synchronisées. TrustPortal terminerait sa partie du cycle plus tôt que prévu, puis passerait le temps restant à attirer d'autres partenaires vers le point de contrôle.
« Chaque fois que vous travaillez avec des partenaires, les sprints ne s'alignent jamais vraiment dans le monde réel », explique Linten. « Il faut compter beaucoup de temps pour revenir en arrière et essayer de rattraper leur retard afin de consolider la fin du cycle de trois mois. »
Scope Screep a suivi. Telefónica a continuellement ajusté ses exigences au fur et à mesure de l'avancement du programme. « De nombreuses entreprises de ce niveau ne résoudront pas le problème. Ils vont coder pour résoudre le problème. » Chaque changement de périmètre accepté sans évaluation par rapport au cahier des charges initial était une dette technique qui s'accumulait discrètement en arrière-plan, à laquelle était jointe une future facture. Des recherches menées dans le cadre de plus de 5 400 projets informatiques ont révélé un dépassement de coûts collectif de 66 milliards de dollars, chaque une année supplémentaire de durée du projet augmentant les dépassements de 15 %, une tendance que TrustPortal surveillait en temps réel.
Puis est arrivée la mise à jour de Blue Prism. Et le personnel du projet a commencé à partir.
Chaque problème semblait différent à première vue. Linten finirait par comprendre qu'ils avaient tous la même cause.
L'approche initiale de TrustPortal pour soutenir le programme était logique. Désignez les personnes possédant la plus grande expertise dans le domaine comme points de contact uniques pour chaque flux de travail. Ce sont ces personnes qui ont le mieux compris le projet. Ils pourraient communiquer le plus efficacement possible avec les équipes partenaires. Ils constituaient le tissu conjonctif de l'accouchement.
Le risque n'était pas visible avant qu'il ne se soit matérialisé.
« Au cours du projet, de nombreuses personnes sont passées à autre chose et nous avons perdu leurs connaissances dans le domaine », se souvient Linten.
Lorsqu'une personne clé partait, les connaissances qu'elle possédait n'étaient pas transmises à un collègue ni à un document. Il a tout simplement disparu du programme.
Sa réponse était structurelle plutôt que procédurale. Il a introduit une exigence minimale de deux personnes possédant une expertise approfondie dans tous les domaines critiques. Non pas parce que c'était une bonne pratique dans l'abstrait, mais parce qu'il venait de voir ce qui se passait lorsque cette redondance n'existait pas.
« Une fois cela fait, nos piles de bogues sont tombées à peu près à néant. »
Une pile de bogues coûte cher. La concentration des connaissances constitue un handicap. Le fait d'exiger que deux personnes détiennent tous les domaines critiques ne représente pas une surcharge de personnel. Il s'agit d'un mécanisme de contrôle des risques dont le rendement est mesurable. La revue de gestion du MIT Sloan identifie la dette technique en tant que passif commercial coûtant aux entreprises américaines plus de 2,41 billions de dollars par an, un chiffre qui reflète précisément le type de coût cumulé que les lacunes en matière de connaissances entraînent lorsqu'elles ne sont pas corrigées. Ce que Linten avait fait, c'était appliquer un principe architectural, éliminer les points de défaillance uniques, au système humain du programme plutôt qu'à ses seules composantes techniques.
Il ne se rendait pas encore compte jusqu'où ce principe l'amènerait.
Debout au beau milieu de la reconstruction de Blue Prism, Linten a vu le lien qui lui manquait.
Les sprints mal alignés, l'écart de portée, la perte de connaissances, les processus défaillants : il ne s'agissait pas de problèmes distincts nécessitant des solutions distinctes. Il s'agissait du même problème exprimé de différentes manières. Chacune d'entre elles a été causée par la distance entre les personnes qui comprenaient le domaine et les personnes qui élaboraient la solution. Distance entre l'organisation qui détenait les connaissances et l'équipe qui en avait besoin. Distance entre le problème métier et l'ingénieur chargé de le résoudre.
Les connaissances nécessaires pour reconstruire ce que Blue Prism avait détruit existaient. Il était assis avec les développeurs d'EY qui travaillaient à l'intégration de l'IVR. Dans le cadre d'une structure normale de gouvernance du programme, la bonne réponse aurait été de soulever officiellement le problème, d'attendre que l'organisation partenaire se mobilise et de gérer le retard par rapport au point de contrôle. Linten ne l'a pas fait.
« Nous avons pris la décision de recruter ces personnes pour qu'elles travaillent pour TrustPortal. »
Il y a eu du refoulement. Absorber les ressources d'une autre organisation n'est jamais simple, et Linten reconnaît que la résistance a été immédiate. Mais la logique commerciale était difficile à réfuter.
« Il était absolument essentiel de rapprocher ces personnes du volet de développement et du processus de développement que nous étions en train de mettre en place pour accélérer la mise en œuvre. »
En réduisant la distance entre les connaissances et l'équipe, Linten a éliminé la principale source de retard du programme. La boucle de feedback qui traversait auparavant les frontières organisationnelles fonctionnait désormais au sein d'une seule équipe. Quand quelque chose se cassait, la personne qui en comprenait la raison se trouvait dans la même pièce que la personne qui le réparait.
C'était l'idée. Il ne s'agit pas d'un principe de gestion ou d'une philosophie de team building. Un constat structurel : chaque niveau de distance organisationnelle entre la connaissance et l'exécution est source de retards, d'erreurs et de risques. Réduisez la distance et les problèmes techniques pourront être résolus. Laissez-le en place et aucun effort d'ingénierie ne compensera.
Réparez d'abord l'architecture humaine. L'architecture technique suivra.
Ce qui s'est passé ensuite chez TrustPortal n'a pas été une simple réorganisation. Il s'agissait de l'application progressive du même principe à tous les aspects du fonctionnement de l'entreprise.
Le premier changement a été la règle de redondance des connaissances, appliquée à l'ensemble du programme. Deux personnes détenant tous les domaines critiques, au minimum. Non pas parce que la prochaine personne à partir provoquerait nécessairement une crise, mais parce que le programme n'avait pas les moyens de le découvrir.
Le second changement était plus radical. Après avoir vu TrustPortal passer du statut de start-up à celui d'entreprise et cumuler les niveaux habituels de management intermédiaire, Linten les a complètement supprimés. Chaque développeur, y compris l'ingénieur le plus débutant, a eu un accès direct aux décideurs du conseil d'administration. Les vendeurs ont appris comment les ingénieurs pensent. Les réalisateurs sont devenus accessibles à tous ceux qui avaient une idée.
« N'importe quel développeur peut demander à n'importe quel professionnel, du vendeur au directeur : j'ai eu cette idée. Pouvez-vous me dire quel est réellement le problème commercial ? »
Il ne s'agit pas d'une préférence culturelle. Il s'agit d'un mécanisme de vitesse et d'un contrôle de qualité. Plus un ingénieur s'éloigne du problème commercial qu'il est en train de résoudre, plus il a de chances d'en résoudre la mauvaise version. Supprimer les couches ne permet pas seulement à l'organisation de se sentir mieux. Cela rend la sortie plus précise. Les recherches de la Harvard Business Review sur les équipes les plus performantes identifie systématiquement le libre accès et la franchise entre les niveaux comme les principaux moteurs de l'efficacité des équipes et des avancées sur le marché, des conditions que la hiérarchie de gestion supprime systématiquement.
Le troisième changement concerne l'intégration. Les nouveaux employés de TrustPortal passent au moins trois mois à s'intégrer avant de contribuer au code de production. Le processus est conçu pour renforcer la compréhension mutuelle au sein de l'équipe, et pas seulement les compétences techniques de la nouvelle recrue. Les ingénieurs apprennent le domaine des affaires. L'entreprise apprend aux ingénieurs. Les questions sont encouragées sans réserve.
« Comme vous avez terminé les trois mois, parce que tout le monde se connaît personnellement et comprend ce qu'il pense, les questions deviennent plus adaptées à l'obtention de résultats. »
Pour tout directeur technique qui évalue si cet investissement est justifié : les équipes qui se comprennent et comprennent le domaine de l'entreprise génèrent moins de malentendus, moins de cycles de retouches et moins de bugs. L'intégration, qui dure trois mois, n'est pas lente. C'est le chemin le plus rapide vers une équipe capable de fonctionner sans intervention constante de la direction.
En ce qui concerne l'architecture d'intégration elle-même, le programme Telefónica a élaboré un principe que Linten a constamment appliqué depuis lors. Les logiciels d'automatisation robotique des processus fonctionnent en définissant des processus au niveau de l'écran et de l'interface : extraction de champs spécifiques, interprétation de résultats spécifiques, navigation dans des interfaces utilisateur spécifiques. Lorsque Blue Prism a mis à jour son architecture sous-jacente, chacune de ces définitions de processus n'a pas été respectée. Le correctif nécessitait une reconstruction complète, pas un correctif.
La leçon à tirer est que la stabilité de l'intégration nécessite la propriété de la pile complète dans la mesure du possible. Chaque niveau de distance entre l'équipe qui construit l'automatisation et l'équipe qui définit les processus qu'elle automatise constitue un risque de maintenance intégré à l'architecture elle-même. Depuis lors, TrustPortal a délibérément maintenu un modèle d'ingénierie complet, avec des connaissances du domaine distribuées entre les équipes plutôt que concentrées sur des individus ou des rôles.
Aucun de ces changements structurels n'a facilité le programme Telefónica. L'intégration de nouveaux membres d'EY à une équipe de mise en œuvre déjà sous pression, dans le cadre d'un programme dont les délais étaient fixés contractuellement, a créé exactement les conditions dans lesquelles les équipes d'ingénierie se sont désengagées.
La réponse de Linten est celle qui surprend le plus les gens lorsqu'ils l'entendent.
Il a consacré dix pour cent de la semaine de travail de chaque ingénieur à la recherche et au développement autogérés, et il a maintenu cet engagement pendant les périodes les plus difficiles du programme.
La justification n'était pas généreuse. Il était opérationnel. Les ingénieurs soumis à une pression de livraison soutenue sans aucune autonomie pendant une partie de leur semaine de travail cessent de penser comme des ingénieurs. Ils optimisent en fonction de la métrique qu'ils ont devant eux, qui, dans un programme de livraison, est l'achèvement au sprint, plutôt qu'en fonction de la qualité et de la longévité de ce qu'ils construisent. Le temps protégé a empêché ce rétrécissement de se produire. Les recherches de HBR sur les connaissances essentielles à la mission révèlent que une croissance durable à grande échelle dépend du transfert de compétences approfondies entre les domaines par des personnes, ce qui ne se produit que lorsque les ingénieurs ont la possibilité de réfléchir au-delà du cycle de livraison immédiat.
« Il n'y a rien de pire que de faire venir quelqu'un de quelque part et de le mettre ensuite dans une chaîne pour qu'il travaille comme dans une usine. Ce n'est pas vraiment ce que pensent les ingénieurs. »
Le retour sur cet engagement s'est concrétisé récemment. Un sprint R&D protégé qui a duré trois mois a jeté les bases d'un tout nouveau produit TrustPortal, mis en œuvre par deux ingénieurs travaillant dans les délais impartis.
Linten a également tenu à montrer aux ingénieurs l'impact direct de leur travail. Dans un programme de cette envergure, il est facile pour quelqu'un qui n'a qu'une seule composante de perdre de vue ce à quoi il contribue. Il a pris l'habitude de relier les gens à l'ensemble. « C'est ce que tu as fait. Regardez-le fonctionner dans le cadre du plus grand projet du monde. C'est votre contribution qui fait réellement une différence significative. » Il ne s'agit pas d'une technique de motivation. C'est de l'information. Les ingénieurs ont besoin de voir le système pour réfléchir sur le plan architectural à leur rôle dans celui-ci.
Ce cadre fonctionne selon trois dimensions intégrées.
La dimension stratégique nécessite une discipline avant toutes les autres : s'approprier le diagnostic avant de déléguer la solution.
La plupart des échecs de livraison commencent par des échecs de planification. Le problème arrive déguisé en problème technique. L'instinct est de le transmettre à l'équipe d'ingénieurs. Cet instinct est faux.
« Si vous avez un problème commercial, c'est parce qu'il n'a pas été planifié correctement au départ. Il est très injuste de prendre ensuite ce problème et de créer un ETA sur la base d'une solution fictive. »
La réponse de Linten a été de créer une architecture d'atténuation parallèlement à l'architecture de livraison. Pour chaque flux de travail, un plan d'urgence existait avant l'arrivée du point de contrôle.
« Vous ne pouvez jamais confier un problème commercial aux ingénieurs et vous attendre à ce qu'ils fassent le travail à votre place. Vous devez prendre des responsabilités au niveau C. »
La planification d'urgence coûte moins cher qu'un échec contractuel. C'est l'analyse de rentabilisation. Tout le reste en découle.
La dimension technique répond à une réalité : chaque niveau de distance organisationnelle entre la connaissance et l'exécution constitue un risque de maintenance intégré à l'architecture.
Lorsque Blue Prism a mis à jour son architecture sous-jacente en milieu de programme, toutes les définitions de processus ont été brisées. Les développeurs d'EY IVR ont acquis les connaissances nécessaires pour résoudre ce problème dans le cadre d'un flux de travail parallèle. Linten n'a pas attendu la gouvernance standard du programme pour le mobiliser.
La boucle de feedback qui traversait auparavant les frontières organisationnelles fonctionnait désormais au sein d'une seule équipe. Quand quelque chose se cassait, la personne qui comprenait pourquoi se trouvait dans la même pièce que la personne qui le réparait.
Depuis lors, TrustPortal a maintenu un modèle d'ingénierie complet. Chaque ingénieur assume la responsabilité de l'architecture en plus de la responsabilité de la livraison. Les connaissances du domaine sont distribuées à dessein et non par hasard.
La dimension culturelle s'est révélée la plus complexe. Les changements structurels qui semblent logiques sur le papier produisent de véritables frictions lorsqu'ils sont appliqués à des personnes soumises à une pression de livraison.
Linten a découvert que les gens réagissent de manière reconnaissable. Certains se sont adaptés immédiatement. D'autres avaient besoin de preuves visibles avant de s'engager. Un plus petit nombre ne s'est jamais complètement adapté. Sa réponse à chaque groupe était structurelle et non motivante. La structure a été modifiée afin que le nouveau modèle produise de meilleurs résultats, et les gens ont pris leurs propres décisions à partir de là.
Les couches de gestion ont été entièrement supprimées. Chaque développeur a eu un accès direct aux personnes qui définissaient les problèmes commerciaux.
« N'importe quel développeur peut demander à n'importe quel professionnel, du vendeur au directeur : j'ai eu cette idée. Pouvez-vous me dire quel est réellement le problème commercial ? »
Les nouveaux employés passent trois mois à s'intégrer avant de contribuer au code de production. Dix pour cent de la semaine de chaque ingénieur est réservée à la RnD autogérée.
Ce temps protégé a jeté les bases d'un tout nouveau produit TrustPortal, livré par deux ingénieurs dans le cadre du sprint qui leur était imparti. L'investissement était opérationnel et non culturel.
Le Schéma de stratégie, issu du génie logiciel, définit une famille d'algorithmes, encapsule chacun d'entre eux et les rend interchangeables, permettant à la logique de décision de varier indépendamment du problème spécifique à résoudre. Il s'agit d'un modèle comportemental conçu dans un souci de flexibilité : un système qui peut changer d'approche au moment de l'exécution sans nécessiter la reconstruction de l'architecture environnante.
Appliquée au leadership organisationnel, la logique est identique. Une entreprise ne doit pas être enfermée dans des structures rigides et dépassées, pas plus qu'un système logiciel bien conçu ne doit être verrouillé dans un seul algorithme. Lorsque l'environnement change, l'approche spécifique change. Le cadre décisionnel sous-jacent ne le fait pas.
Linten n'a pas utilisé ce langage pour décrire son approche. Mais chaque décision qu'il a prise dans le cadre du programme Telefónica et chaque changement qu'il a apporté à TrustPortal depuis lors, le même schéma est visible : diagnostiquer d'abord le problème structurel, aborder l'architecture humaine avant l'architecture technique et appliquer la même logique, que le défi soit lié au mauvais alignement des partenaires, à la perte de connaissances ou à l'arrivée d'une IA agentique.
Le programme Telefónica a été achevé dans les délais. TrustPortal a transformé les opérations de la plus grande entreprise d'Espagne.
Plus important encore, le schéma s'est révélé transférable. Depuis lors, Linten a appliqué le même cadre de diagnostic à chaque décision importante prise par TrustPortal : le même séquençage, la même lentille structurelle, le même instinct d'examiner l'architecture humaine avant de rechercher une solution technique.
Le test actuel de cette transférabilité est l'IA agentique. Les ingénieurs de TrustPortal sont en train de passer de l'écriture directe de code à l'orientation des agents d'IA vers des résultats architecturaux. La résistance que Linten rencontre est reconnaissable. Les personnes compétentes qui ont construit leur identité professionnelle autour d'un ensemble d'outils sont invitées à modifier complètement leur relation avec ces outils. L'instinct est de continuer à chercher ce qui est familier. Gartner prédit que 40 % des applications d'entreprise seront intégrées à des agents d'IA spécifiques à des tâches d'ici la fin de 2026, en effectuant la transition, Linten gère non pas une considération future mais un défi de livraison actuel.
Sa réponse suit le même schéma. Il n'impose pas l'adoption et ne mesure pas la productivité par rapport aux objectifs de production de l'IA. Il redéfinit le rôle au niveau de l'architecture : il ne s'agit pas d'un développeur qui écrit des lignes de code, ni d'un ingénieur rapide qui saisit des instructions, mais d'une personne qui comprend suffisamment l'architecture de l'entreprise pour orienter un programme vers le résultat correct. Et il protège l'espace dans lequel les ingénieurs peuvent expérimenter la nouvelle approche avant qu'elle ne devienne une exigence de livraison.
Le défi le plus profond pour lequel il conçoit déjà est social. « Les gens utilisent des outils agentiques et sont de moins en moins connectés avec les personnes qu'ils connaissent, car ils dépendent de moins en moins des informations qu'ils ont en tête et passent par l'IA pour obtenir les mêmes informations. » Les connexions humaines qui font fonctionner son modèle peuvent être mises à rude épreuve car l'IA absorbe une plus grande partie de la fonction de recherche d'informations que la conversation humaine assurait autrefois. Maintenir les conditions d'une véritable collaboration au sein d'une équipe dont les membres interagissent de plus en plus avec l'IA plutôt qu'entre eux est le prochain problème structurel qu'il s'apprête à résoudre.
Il ne connaît pas encore la réponse. Mais il sait quelle question poser en premier.
Trois catégories d'activités apparaissent une fois le diagnostic structurel terminé.
Investir dans des structures de prestation qui concentrent les connaissances essentielles du domaine sur des individus individuels. Des couches de gestion qui augmentent la distance entre les problèmes commerciaux et les personnes qui les résolvent. Les délais et les ETA appliqués à des problèmes qui n'ont pas encore été correctement diagnostiqués et maîtrisés au niveau organisationnel approprié.
Redondance structurelle pour les connaissances des domaines critiques dans chaque programme, avec un minimum de deux personnes possédant une expertise approfondie dans chaque domaine. L'accès direct entre les équipes d'ingénierie et les décideurs au niveau du conseil d'administration constitue une condition opérationnelle standard, et non une exception. Temps réservé à l'exploration autonome, même sous pression de livraison, en tant qu'investissement opérationnel plutôt que comme geste culturel.
Engagements clients et normes de qualité existants dans tous les programmes actifs. L'habitude diagnostique qui consiste à évaluer l'architecture humaine avant de tenter de corriger l'architecture technique. Des processus d'intégration qui donnent la priorité à la compréhension mutuelle avant la contribution à la production.
Linten explique clairement ce qui rend cela difficile dans la pratique. « Vous ne pouvez jamais confier un problème commercial aux ingénieurs et vous attendre à ce qu'ils fassent le travail à votre place. Vous devez prendre des responsabilités au niveau C. »
Il ne s'agit pas d'une observation culturelle. Il s'agit d'une exigence structurelle. Tant que la défaillance de l'entreprise n'est pas correctement diagnostiquée et prise en charge au bon niveau, le fait de la transmettre à l'équipe de livraison entraîne exactement le type d'effort coûteux et mal orienté auquel le programme Telefónica a dû faire face avant les changements structurels.
Les détails spécifiques du programme Telefónica sont déjà historiques. Les partenaires impliqués, les conflits de versions, les intégrations IVR : rien de tout cela n'est important.
Ce qui reste pertinent, c'est le cadre décisionnel que Linten a développé en surmontant chaque échec produit par ce programme. Non pas en les planifiant à l'avance, mais en reconnaissant leur schéma une fois qu'ils se sont produits et en élaborant une réponse structurelle qui empêcherait qu'un même échec ne se reproduise sous une forme différente.
La leçon à tirer n'est pas de recruter des développeurs partenaires, de supprimer les cadres intermédiaires ou de protéger dix pour cent du temps consacré à l'ingénierie. Il s'agissait de la mise en œuvre spécifique d'un principe plus général. La leçon est de corriger l'architecture humaine avant de passer à la solution technique, de réduire la distance entre la connaissance et l'exécution, et d'appliquer cette logique de manière cohérente à mesure que l'environnement change autour de vous.
« La technologie évolue, mais pas les humains à long terme. Les humains se comportent d'une manière particulière et il faut être capable d'y faire face. »
La seule certitude, c'est que le défi structurel viendra. Une personne clé va partir. Un partenaire va prendre du retard. Une mise à jour de version détruira ce que vous avez créé. Une nouvelle technologie va arriver et les ingénieurs qui maîtrisaient la précédente résisteront à la transition. À ce stade, la question n'est pas de savoir si vous disposez de la bonne technologie. Il s'agit de savoir si vous avez construit l'architecture humaine capable d'y répondre.
Si vous souhaitez discuter de la manière dont ce cadre peut être appliqué à la transformation technologique, à la migration des plateformes ou aux décisions technologiques stratégiques de votre organisation, veuillez contactez notre équipe.
Alexandra Mendes est spécialiste senior de la croissance chez Imaginary Cloud et possède plus de 3 ans d'expérience dans la rédaction de textes sur le développement de logiciels, l'IA et la transformation numérique. Après avoir suivi un cours de développement frontend, Alexandra a acquis des compétences pratiques en matière de codage et travaille désormais en étroite collaboration avec les équipes techniques. Passionnée par la façon dont les nouvelles technologies façonnent les entreprises et la société, Alexandra aime transformer des sujets complexes en contenus clairs et utiles pour les décideurs.
People who read this post, also found these interesting:
