Les technologies digitales ; la Tech en version courte ; est un des outils essentiels au coeur du développement de la plupart des entreprises.
Certaines entreprises vont trouver des réponses dans des outils du marché, qu'ils soient SaaS ou On Premise, paramétrables ou psycho-rigides, payants ou gratuits.
D'autres vont devoir mettre en oeuvre des solutions sur mesure qu'elles développeront, ou dont elles confieront le développement à des tiers.
Elles sont ainsi confrontées à la gestion d'équipes Tech et attendent d'elles qu'elles soient en mesure de créer des solutions informatiques les plus performantes possibles avec les technologies les plus efficaces du moment.
Autrement dit, ces entreprises sont dans une recherche de la meilleure maîtrise des solutions techniques qui leur sont utiles pour être en capacité de livrer en production - le Delivery - et d'innover.
Choisir un périmètre technologique.
Chaque solution informatique repose sur une stack technique : un ensemble de technologies, de langages, de modèles de conception, d'approches cohérentes.
Citons par exemple une stack Java, Kotlin, Javascript dans des approches itératives et devops.
Cela peut sembler restreint au profane, mais si on s’amuse à rassembler quelques noms de techno et langages que cela induit, ça donne vite ça :
En théorie, il n'y a pas de problème technique à envisager que chaque projet soit lancé avec une stack technologique qui lui est propre, sans se soucier de ce qui a déjà été utilisé.
Le problème se pose dès lors qu'il faut faire vivre ces projets, par exemple les faire évoluer : il faut disposer des compétences techniques capables de le faire en an maîtrisant tous les aspects.
Si les stacks retenues sont différentes, le développeur capable d'intervenir sur l'une d'entre elle ne sera pas capable d'intervenir sur l'autre.
Cela implique donc de multiplier les équipes, de fonctionner en silo et de ne pas pouvoir mutualiser les tâches : chaque équipe doit être alimentée individuellement et ne peut pas aller en renfort d'une autre équipe.
La multiplicité des technologies implique également des difficultés pour exploiter les projets - chaque stack technique vient avec ses propres contraintes d'exploitation -, pour recruter en évaluant correctement la compétence, pour former etc.
C'est pourquoi, la plupart des entreprises ayant une DSI s'imposent de choisir un périmètre technologique précis. Ce faisant, elles espèrent en maîtriser toutes les facettes ; et être à la fois en capacité de les utiliser pour “faire du delivery”, mais aussi de les pousser dans leurs limites, les faire évoluer pour faire de l’innovation.
Le choix du périmètre doit être effectué avec discernement.
Si le choix conduit à un périmètre technique trop restreint, il sera alors impossible de susciter de l’intérêt dans la durée. En effet, dans le monde de l'ingénierie, les collaborateurs ont la chance de pouvoir demander des challenges, c'est-à-dire d’être confrontés à des problèmes qui contiennent une part de risque qui trouvera des solutions en mobilisant une nouvelle technologie, une nouvelle approche ou un nouvel outil.
Autrement dit, un périmètre trop restreint limitera les possibilités de challenge ou d'innovation en restant dans le dit périmètre et donc provoquera soit un désintérêt des ingénieurs et une démotivation (“j’ai l’impression d’avoir fait le tour”), soit une ouverture incontrôlable vers d’autres périmètres technologiques qui peuvent aller jusqu’à faire perdre toute forme de cohérence dans les savoirs-faires.
A l’échelle d’un projet, on retrouve exactement ce type de comportement : un projet est par construction un écosystème fermé dans lequel l’architecte a fixé le terrain de jeu technique.
Il a veillé à choisir des technologies qui permettront de répondre aux enjeux du projet ; tout en facilitant le sourcing de l’équipe avec des ingénieurs motivés.
Si le projet dure, qu’il n’y a pas de processus de refactoring technique organisé, certains auront l’impression de tourner en rond et souhaiteront quitter le projet.
D’autres, à l’inverse, feront tout pour faire évoluer les framework existants, en ajouter d’autres ou même intégrer de nouveaux langages.
Au final, le projet perdra des membres motivés de son équipe, et verra sa complexité technique augmenter qu’il y ait eu ou non une analyse technique préalable.
En revanche, si à l’échelle d’une société, le périmètre technique est trop ambitieux ; il sera extrêmement difficile d’atteindre un niveau d’expertise suffisant pour en maîtriser toutes les facettes.
Il sera peut être plus facile de susciter de l’intérêt notamment dans un processus de recrutement “en ratissant large” ; mais le collaborateur avisé ne s’y trompera pas longtemps en découvrant qu’il ne progressera pas faute de maîtrise de la part de ses collègues.
Les sirènes du non choix.
Certaines sociétés sont également tentées par le non choix, c'est -à -dire de partir du principe que les exigences clients, les contraintes projets et les envies des équipes technique assureront un choix pertinent.
Pour moi, une devise de Pierre Rouxel, prêtée aux Shadoks, la résume parfaitement :
Le non choix conduit invariablement à ce qu’il cohabite au sein de la société des équipes qui maîtrisent parfaitement leur sujet sur un périmètre donné et restreint, et d’autres ne maîtrisant pas ce qu’elles font.
Autrement dit, la société ne sera pas capable d’assurer une qualité constante - ou au moins minimale - de ses livrables, et elle ne sera pas en mesure non plus de mettre en place des politiques de gestion de la compétence de qualité intégrées du fait de la diversité des technologies, des profils et de leurs attentes en terme d’accompagnement.
Elle ne sera pas plus capable d’en anticiper les changements avec discernement car le travail de veille sur un périmètre trop large devient vite une gageure.
Le périmètre technique doit être aussi considéré dans une dimension dynamique.
Il est également important de considérer ce périmètre technique dans une dimension dynamique : chaque technologie dispose de son propre cycle de vie, qui intègre à chaque palier des risques et des opportunités. Et de cette dynamique naît également la nécessité de considérer que pour une société, le choix du périmètre technologique doit être un processus en continu ; ce qui ne veut pas dire que l’on choisirait à chaque instant de modifier le périmètre !
Chacun connaît les grands principes du “hype cycle”, par exemple très largement utilisés par le Gartner.
Cela reflète parfaitement la dynamique d’une technologie ou d’un outil avant qu’il ne devienne vraiment utile. Toutes les phases sont autant de risques et d’opportunités qu’il convient d’intégrer dans le choix de son périmètre technologique, mais aussi dans la manière d’utiliser les opportunités qui en découlent pour susciter de l’intérêt au niveau des équipes, et donner au niveau des projets des avantages concurrentiels issus des choix technologiques.
Ce qu’il se passe après le plateau de productivité est tout aussi important, car cela va aider à déterminer la nécessité de changer de technologie et de quelle façon.
Concrètement, une technologie en plateau est idéale pour faire du delivery : il existe suffisamment d’ingénieurs formés et maîtrisant la technologie, les ressources de formation sont nombreuses, les communautés techniques proposent des solutions à de nombreux problèmes, le coût de mise en oeuvre des projets avec ces technologies est déterminable et en retenir une ne représente pas un risque au niveau des responsables.
De manière tout aussi évidente, ce qu’il y a au bout du plateau est forcément une forme plus ou moins poussée d’obsolescence pour cette technologie : à un moment, la technologie sera considérée comme périmée.
Les indices qui permettent de déceler ce moment sont nombreux, par exemple : une perte d’appétence chez les jeunes ingénieurs, une communauté qui s’essouffle, moins de projets qui démarrent en embarquant ces technologies, le principal promoteur (quand c’est open source) ou éditeur s’en désengage, un rythme d’évolutions moins rapide.
Ces indices là sont des conséquences de la perte de vitesse de la technologie : il est donc déjà trop tard pour préparer la suite ; à moins d’être très rapide à la réaction et de pouvoir mobiliser rapidement des ressources dans l’entreprise pour former à des technologies qui les remplaceront.
D’autres indices permettent d’anticiper une tendance : par exemple, la mise à disposition d’une nouvelle interface homme/machine (l’Iphone par exemple) ou d’une approche souple de l’exploitation de ressources informatiques (les clouds par exemple) va forcément pousser à l’émergence de nouveaux langages et frameworks pour interagir avec.
De la même manière, de nouvelles attentes des utilisateurs finaux impliqueront que les lignes bougent fortement vis -à -vis des fournisseurs de technologies pour y répondre. C’est ce qui est en train de se produire à l’échelle mondiale avec l’appétence des citoyens pour des modes de déplacement décarbonés.
Les leaders de maintenant seront donc probablement challengés par de nouvelles initiatives qu’il conviendra d’évaluer.
A l’échelle d’une entreprise, il y a plusieurs façons d’appréhender cette obsolescence programmée, que je préfère continuer de nommer “dynamique”.
Ne rien faire. Cela peut sembler choquant, mais cette solution est souvent très efficace dans de nombreux contextes.
En effet, chaque projet a une durée de vie estimée à l’avance, dont il est probable qu’elle soit prolongée. Même une centrale nucléaire finira par être décommissionnée.
Dès lors, la problématique se limite à assurer que l’on disposera d’une main d'œuvre résiduelle suffisante, que la technologie obsolète aura du support pendant la durée de vie restante et que le dit projet aura un remplaçant au moment de sa fin de vie.
Anticiper. Faire de la veille, surveiller les indices précurseurs, tester ce qui peut être des candidats à la suite. La manière la plus efficace et indolore de réaliser ces actions est de toujours disposer de projets d’innovation et de R&D qui seront le support de ces travaux visant à anticiper les changements technologiques.
La contrainte est que l’entreprise accepte de mener des projets qui ne sont pas directement liés à son cœur d’activité et dont le taux d’échec est important.
Réagir. C’est accepter d’être dans un laps de temps dans une posture moins idéale vis à vis des concurrents : les projets ont un peu de retard sur les technologies utilisées, le recrutement du personnel technique est un peu plus difficile, le changement technologique se fait à marche forcée, laissant d’autant moins de place pour la création de nouvelles fonctions pour les clients.
C’est pourtant une solution efficace pour les entreprises qui n’ont pas vocation à mener des actions de R&D fortes sur des périmètres technologiques : elles centrent leurs opérations de R&D sur leur métier, et profitent de l’expertise d’autres entreprises pour se mettre à niveau technologiquement le moment venu.
Dans les faits, la totalité des entreprises qui ne sont pas à uniquement à vocation technologique effectueront leurs arbitrages techniques en s’appuyant sur leurs arbitrages métier. Sur cet axe Métier, elles devront également choisir entre une stratégie Ne rien faire/Anticiper/Réagir.
Ainsi, une entreprise établie qui dispose d’un atout concurrentiel sur son métier est probablement sur cet axe dans une approche “Anticiper”.
Elle peut tout à fait se satisfaire sur les enjeux techniques d’une approche “Réagir” ; car l’avance dont elle dispose sur les aspects métiers lui permettra d’amortir les impacts des changements technologiques.
Pour une startup (à vocation non essentiellement technologique pour l’exemple), l’approche vis-à-vis de la technique et du métier peut se considérer par rapport à ses étapes de levée de fonds.
Le tableau suivant peut représenter le profil d’arbitrage d’une startup misant tout sur le métier et le TTM.
(Note de l'auteur : il existe aussi des startups qui tout en misant tout sur le TTM et leur métier, sont aussi déterminées à utiliser le meilleur de la Tech dès le départ ; sans que cela ne les ait empêchées d'atteindre le statut de Licorne !)
Il ressort ainsi que la prise en compte dans son périmètre technique de la dynamique d’évolution de ces technologies est tout aussi importante que le choix initial des technologies. Cela peut affecter significativement la performance globale de l’entreprise.
Nous pensons donc qu’il est judicieux d’encourager les entreprises, les projets et les développeurs à faire des choix quant au périmètre technique qu’ils adressent ; et à se donner les moyens de maîtriser les technologies, les langages, les frameworks, les démarches qui s’y rapportent.
Ce choix doit être effectué en assumant que ce faisant, le champ du possible “potentiel” est volontairement restreint au profit du champ du réalisable “en maîtrise” ; ce qui permet d’obtenir des solutions pérennes pour les clients finaux.
Nous pensons que la dynamique impliquée par l’évolution constante des technologies est une opportunité qu’il faut saisir pour constamment éprouver et challenger le périmètre technique actuel et déterminer à quel moment il est possible ou nécessaire de le faire évoluer fortement.
En trois mots : assumer, maîtriser, anticiper.
La problématique des DSI vis-à-vis des technologies digitales qui seront utilisées pour ses projets se résume finalement en 3 idées :
Assumer.... de se focaliser sur un champ technologique précis, sans pour autant être pauvre. Cette stack doit permettre de répondre aux besoins essentiels des projets ; elle est parfois la meilleure réponse, et d'autres fois une réponse "qui fait le job".
Maîtriser... la stack technologie retenue en recrutant et formant ses collaborateurs, en leur donnant les moyens de comprendre pourquoi cette stack a été retenue, ce qu'elle sait et ce qu'elle ne sait pas adresser.
Anticiper... l'évolution de la stack. Un choix est par essence une approche statique - je fais un choix maintenant - alors que la Tech est une matière mouvante, dont la dynamique d'évolution est connue et impossible à stopper ou ralentir.
Il faut donc accepter notamment de faire évoluer sa stack en continu, pour être capable de se projeter longtement dans l'avenir en repoussant un big bang technologique au moment où il sera cohérent avec les enjeux business.
Sources / crédits :
Hype Cycle - Par NeedCokeNow — Travail personnel, CC BY-SA 3.0, https://commons.wikimedia.org/w/index.php?curid=27546041
Image shadoks : https://shadoks.fandom.com/fr/wiki/Wiki_Shadoks
