.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.
Tiago Franco, fondateur et directeur général d'Imaginary Cloud, a été confronté à un défi auquel toutes les entreprises technologiques sont finalement confrontées. L'expertise qui avait fait le succès de son entreprise était en train de perdre du terrain. Non pas parce que la technologie elle-même avait perdu sa maturité technique ou sa robustesse, mais parce que sa pertinence sur le marché avait diminué à mesure que l'industrie évoluait vers une gamme technologique différente.
Au cours des premières années, Imaginary Cloud a réalisé des projets principalement en Ruby on Rails. Ensuite, les prospects ont commencé à rejeter les propositions de plus en plus fréquemment, en grande partie à cause de l'infrastructure technologique. La raison en était simple : React et Node.js étaient les nouveautés les plus populaires.
Ce n'est pas parce qu'il a réussi cette transition que l'expérience de Franco mérite d'être examinée. Ce n'est pas l'échec qui en fait sa valeur, mais le fait que la transition n'était pas structurée, difficile et coûteuse avant l'émergence d'une approche systématique qui pourrait être appliquée aux futurs changements technologiques. Voici un compte rendu de ce voyage et des leçons qu'il a révélées.
Franco a fondé Imaginary Cloud, un cabinet de conseil en transformation numérique basé au Portugal qui aide les clients à livrer et à être présents dans l'espace numérique. Depuis sa création en mai 2010, la société a contribué au développement de plus de 300 produits numériques en Europe, aux États-Unis et au Moyen-Orient, au service de clients tels que Nokia, BNP Paribas et Thermo Fisher. L'entreprise emploie aujourd'hui plus de 100 professionnels répartis dans quatre bureaux à travers le monde et maintient un taux de recommandation des clients de 99 %.
Il a créé Imaginary Cloud après avoir travaillé comme ingénieur logiciel et chef de projet pour des organisations telles que le CERN, l'Agence spatiale européenne et le ministère britannique de la Défense. Ce qui a caractérisé ces organisations, c'est leur profonde dépendance à l'égard de l'innovation et de la recherche et du développement, un état d'esprit que Franco a intégré à Imaginary Cloud.
Cependant, cette orientation était en grande partie motivée par une perspective d'ingénierie plutôt que par rapport aux objectifs de l'utilisateur, une tension qui l'a amené à croire que le processus de développement devait changer.
La thèse fondatrice abordait ce que Franco considérait comme un problème récurrent : les logiciels centrés sur la qualité sont souvent difficiles à utiliser et sujets à des erreurs humaines car ils ne sont pas centrés sur l'utilisateur. Sans une conception centrée sur l'utilisateur, la qualité technique ne se traduit pas par une utilisation efficace et fiable. » Imaginary Cloud fusionnerait les deux approches.
Ruby on Rails est devenue la technologie principale parce qu'elle s'inscrivait dans cette vision. Au cours des premières années, la stratégie a porté ses fruits et l'entreprise a réalisé des dizaines de projets à travers le monde. Ensuite, le marché a évolué, influencé en partie par La décision de Facebook d'ouvrir React et promouvoir de nouvelles approches architecturales privilégiant les piles basées sur JavaScript telles que React et Node.js par rapport aux frameworks plus traditionnels. Aujourd'hui, les entreprises sont confrontées à un défi similaire avec les technologies d'IA, où les pressions d'adoption rapides peuvent rendre les outils ou les processus établis obsolètes.
Le changement s'est produit plus rapidement que Franco ne l'avait prévu. React et Node.js, qui représentent un élément fondamental transition architecturale des modèles monolithiques vers des modèles de microservices, est devenu ce que Franco décrit comme « celui par lequel chaque client voulait commencer ». Ruby on Rails « a cessé d'être une technologie souhaitable pour démarrer un nouveau projet ».
Le paradoxe était critique. Imaginary Cloud proposait des solutions Ruby on Rails techniquement supérieures pour les produits en phase de démarrage que la plupart des clients développaient, et 30 à 40 % moins chères que les alternatives de microservices. Pourtant, les clients ont rejeté ces propositions uniquement en raison de la technologie.
« Le client n'obtenait pas plus de valeur. Le client obtenait moins de valeur parce qu'il payait plus cher pour une technologie moins adaptée au stade dans lequel il se trouve, mais il n'achetait tout simplement pas cette technologie. »
Franco a décidé de transférer l'ensemble de l'entreprise vers React et Node.js. Mais il n'avait aucune approche systématique pour exécuter cette transformation. Il en a résulté ce qu'il qualifie aujourd'hui de profonde inefficacité.
Lorsqu'on lui demande comment il a défini le problème et comment il a communiqué la stratégie de transition à l'entreprise, Franco répond directement : « Je ne l'ai pas fait. C'est le but. C'est ce qui a changé en moi en tant que leader au fil des ans. Au début, je ne savais pas comment gérer ce changement. »
Au lieu d'un plan structuré, Franco a pris des mesures immédiates. « Nous avons commencé à réaliser des projets dans Node et React, et tout était très orienté vers l'action. » Certains clients ont toutefois accepté ces propositions à des prix plus élevés, même si React et Node.js étaient moins adaptés à leurs besoins en matière de produits à un stade initial, nécessitant des efforts d'ingénierie nettement plus importants que les solutions Ruby on Rails comparables. Les projets ont commencé, mais des problèmes sont rapidement apparus : la pile était nouvelle et il s'agissait des premiers projets de l'entreprise à l'utiliser.
La résistance était prévisible, mais elle n'était pas préparée. Les ingénieurs qui maîtrisaient Ruby on Rails ont vu des collègues explorer d'autres directions. « Il est naturel que les gens expérimentent de nouvelles technologies, et c'est une bonne chose », explique Franco. « Certains ingénieurs ont exploré React ou d'autres outils comme Elixir. Mais c'est à l'organisation de décider quoi adopter. »
« Nous venons de commencer à faire des choses et certaines personnes ont fait preuve de résistance. Nous avons fini par les utiliser dans des projets Node.js, dont certains ont été adaptés. Je dirais que la majorité l'a fait après un certain temps. Mais je n'ai pas communiqué d'orientation stratégique en disant que c'est dans cette direction que nous devons aller. C'était comme si nous avions commencé à faire des choses. C'était inefficace. »
Cette avancée est due à la reconnaissance d'un schéma que Franco avait rencontré à plusieurs reprises.
Comme il l'explique :
« Ce qui vous y mène habituellement ne vous amène pas à l'étape suivante. L'environnement a donc changé, et vous devez changer avec lui. »
Cela se produit, note Franco, « très souvent. Cela se produit généralement tous les deux ou trois ans lorsque vous devez adapter la façon dont vous distribuez les logiciels simplement en raison de l'évolution de l'environnement. »
Franco se souvient également des conseils d'un professeur d'université qui a déclaré à un collègue directeur général :
« Le plan stratégique doit être modifié le moins possible et aussi souvent que nécessaire. »
Le paradoxe reflétait ce que Franco était en train d'apprendre : la stratégie nécessite un engagement sur des périodes de trois à cinq ans, mais le strict respect des stratégies qui échouent garantit l'obsolescence.
« Les techniques que j'applique aujourd'hui pour faire face à ce changement sont complètement différentes. Ils sont plus matures qu'ils ne l'étaient au début. » La différence provenait de l'apprentissage par l'expérience et de la recherche d'une formation formelle en stratégie d'entreprise, ce qui lui a permis d'aborder les transitions dans un cadre systématique plutôt qu'improvisé.
Ce qui est ressorti de multiples transitions, la première était chaotique, la seconde légèrement meilleure, la troisième plus systématique, est ce qu'il identifie aujourd'hui comme un schéma reproductible.
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 ainsi aux algorithmes de varier indépendamment du code qui les utilise.
Il s'agit d'un modèle comportemental conçu pour apporter de la flexibilité et éviter les comportements codés en dur. Par exemple, vous pourriez avoir une fonction telle que calculate_time_home (stratégie), où la stratégie pourrait être l'itinéraire le plus rapide, une promenade panoramique ou une autre approche.
Tout comme les logiciels peuvent échanger des algorithmes au moment de l'exécution lorsqu'ils sont mis en œuvre à l'aide du Strategy Pattern, une entreprise ne doit pas être enfermée dans des pratiques rigides et dépassées. Les organisations peuvent modifier leurs processus ou leurs technologies sans avoir à réécrire l'ensemble du système, ce qui les rend plus flexibles et faciles à gérer plutôt que fragiles et obsolètes.
Lorsqu'on lui a demandé de décrire ce que les autres dirigeants devraient faire face à des transitions similaires, la réponse de Franco révèle l'essentiel du schéma : « La première chose à faire est de décider de la nature de ce changement et de la direction dans laquelle ils vont aller. Une fois que cela est décidé, vous devez arrêter de faire ce qui doit être arrêté, et vous devez commencer à faire tout ce qui doit être commencé pour atteindre cet objectif. »
Mais avant tout cela, Franco souligne :
« Avant de comprendre ce que vous devez arrêter de faire, vous devez comprendre où vous allez. Faites un diagnostic de leur situation actuelle et de l'évolution du secteur, puis définissez une stratégie. »
Ce cadre fonctionne selon trois dimensions intégrées qui, selon Franco, doivent être abordées simultanément.
La première leçon de Franco a été de distinguer les changements structurels du marché des fluctuations temporaires. Ruby on Rails n'a pas disparu. Il a tout simplement cessé d'être le choix par défaut pour les nouveaux projets. Cette distinction était importante.
Au cours de la transition entre Ruby et React, le diagnostic a révélé une vérité embarrassante. Les clients exigeaient une technologie offrant moins de valeur à un coût plus élevé. Mais la demande était constante sur tous les marchés et s'est maintenue dans le temps. Cela indiquait un changement structurel et non une tendance temporaire.
L'approche mûre de Franco, développée après l'échec initial, implique une planification stratégique explicite : « Nous élaborons une stratégie et concevons une stratégie sur trois ans. C'est ce que nous voulons atteindre. »
Mais le plan doit être communiqué avec une clarté absolue :
« Vous faites le diagnostic, vous préparez la stratégie, puis vous vous assurez que la stratégie peut être présentée à tout le monde sur une seule page. Ensuite, vous partagez cette stratégie avec tout le monde. »
La dimension technique répond à une réalité que Franco a apprise par l'expérience : les transitions ne peuvent pas se produire instantanément. Imaginary Cloud n'a pas complètement abandonné Ruby on Rails. Les projets clients existants se sont poursuivis avec leur technologie d'origine. Nouveaux projets lancés dans React et Node.js.
La solution développée par Franco consistait à créer des communautés de pratique.
« Nous avons fini par créer ce que nous appelons des communautés de pratique, où les gens pouvaient partager leurs connaissances sur la technologie qu'ils utilisent. »
Ces communautés remplissaient de multiples fonctions : accélérer le transfert de connaissances, créer des preuves sociales grâce à des cas de réussite visibles et établir des normes sans goulots d'étranglement centraux.
Franco a également dû restructurer ses équipes. « Nous avons dû séparer la spécialisation front-end de la spécialisation back-end en raison des forces du marché. Avant, nous n'en avions pas. C'était tout simplement complet. » Cette séparation a créé de nouveaux défis de coordination que les communautés de pratique ont contribué à relever.
Le dimension culturelle s'est révélée la plus complexe. Franco explique que les gens réagissent différemment au changement.
Certains adoptent immédiatement la nouvelle technologie et en deviennent les premiers à l'adopter. D'autres résistent au début, mais une fois qu'ils voient leurs collègues obtenir des résultats et profiter des avantages de l'adoption, ils emboîtent progressivement le pas. Enfin, certains choisissent de ne pas s'adapter et peuvent quitter l'organisation si le changement entre en conflit avec leurs préférences ou leurs principes. « Lorsqu'une organisation change, certaines personnes s'y adaptent, d'autres non. Il est essentiel de comprendre cette dynamique, et c'est une leçon qui s'applique à toute transition. » Franco note.
Le cadre de Franco reconnaît trois populations. Les premiers utilisateurs accueillent le changement avec enthousiasme. Les pragmatistes s'adaptent lorsque les preuves de succès deviennent évidentes. Les opposants préfèrent l'ancienne approche et considèrent la transition comme inutile ou malavisée.
« Le leadership est synonyme de changement. Le leadership définit l'orientation et veille à ce que le changement se produise. Le changement est compliqué. Lorsque des changements se produisent, nous ne savons parfois pas si vous avez raison ou si vous avez tort, mais nous devons aller dans cette direction précise. »
La validation du modèle de Franco repose sur des résultats mesurables. Imaginary Cloud a maintenu son taux de recommandation client de 99 % tout au long de la transition, malgré la courbe d'apprentissage et l'augmentation des coûts des projets au cours de la période de transformation de 18 mois. Au cours de cette période, l'entreprise a également remporté Un endroit où il fait bon travailler lors de leur première inscription, et la fidélisation de la clientèle est restée supérieure à la moyenne du marché.
Plus important encore, le schéma s'est avéré transférable. Franco a appliqué le même cadre aux transitions suivantes, notamment aux architectures cloud natives, à l'informatique sans serveur et à l'intégration de l'intelligence artificielle. Chaque transition s'est déroulée plus facilement car l'approche systématique a remplacé l'improvisation.
Trois catégories d'activités apparaissent une fois que l'orientation est établie.
Investir dans des capacités qui vont à l'encontre de l'orientation stratégique. Des services marketing que le marché n'apprécie plus. Une résistance active qui mine les initiatives stratégiques. Comme l'explique Franco : « Si vous changez de stratégie, si vous changez de direction, la stratégie vous indiquera ce que vous devez arrêter de faire. »
Renforcer les capacités stratégiques malgré les coûts immédiats. Mesurer les progrès de la transition à l'aide de mesures spécifiques. Communiquer la justification stratégique à plusieurs reprises jusqu'à ce que le message soit intégré à la conscience organisationnelle.
Engagements clients existants. Des normes de qualité malgré les pressions en matière d'efficacité. Positionnement sur le marché en modifiant uniquement la mise en œuvre technologique.
Franco souligne que les transitions réussies préservent plus qu'elles n'en jettent. Pendant la transition de Ruby à React, le modèle opérationnel, les relations avec les clients et le positionnement sur le marché d'Imaginary Cloud sont restés constants. Seule la mise en œuvre technologique a changé. Cela a empêché toute tentative de transformation simultanée sur plusieurs dimensions.
- Solutions interchangeables : Le même cadre s'applique qu'il s'agisse de modifier les technologies, d'adopter l'IA ou de restructurer des équipes. La logique de décision reste constante, même si les défis spécifiques changent.
- Logique indépendante du contexte : La séquence de décision s'applique aux startups et aux entreprises, bien que l'exécution varie. Une entreprise de 20 personnes et une organisation de 2 000 personnes sont confrontées à des défis de mise en œuvre différents mais suivent le même schéma stratégique.
- Maintenable à grande échelle: Comme Franco l'a appris, le fait d'avoir un schéma clair permet d'éviter le chaos lié à la gestion ad hoc du changement. « Cela se produit très souvent », note-t-il. « Cela se produit généralement tous les deux ou trois ans, lorsque vous devez adapter la façon dont vous distribuez les logiciels simplement en raison de l'évolution de l'environnement. »
D'autres dirigeants peuvent adopter l'approche de Franco non pas parce qu'ils sont confrontés au même défi technologique, mais parce qu'ils sont confrontés au même schéma de changement environnemental nécessitant une adaptation stratégique. Les outils changent, mais le cadre décisionnel reste robuste.
Le parcours de Franco de Ruby on Rails à React est déjà dépassé, mais c'était l'un des premiers défis qu'il a dû relever. Cependant, son cadre de gestion du changement reste pertinent car il s'agit d'un modèle stratégique : une logique de décision indépendante du contexte qui s'adapte à tous les défis.
La leçon à tirer n'est pas « d'adopter des microservices » ou une technologie spécifique. La leçon à tirer est de surveiller systématiquement les changements, que ce soit dans l'IA, les frameworks logiciels ou les modèles commerciaux, de diagnostiquer avant d'agir, de tester avant de s'engager et de communiquer honnêtement.
Ce modèle fonctionne que vous soyez une société de logiciels comptant 50 employés ou 5 000 employés, que vous changiez des technologies ou des modèles commerciaux, et que votre « moment Ruby on Rails » survienne au prochain trimestre ou dans cinq ans.
La seule certitude est que votre moment viendra : les propositions seront rejetées, les compétences de base deviendront obsolètes et l'environnement changera. À ce stade, vous devez choisir de vous adapter intentionnellement, sinon vous risquez d'être laissé pour compte.
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.
CEO @ Imaginary Cloud et co-auteur du livre Product Design Process. J'aime la nourriture, le vin et le Krav Maga (pas nécessairement dans cet ordre).
People who read this post, also found these interesting:
