Le contexte
Lorsque j’ai rejoint cette entreprise en tant que CTO, la situation technique et humaine était devenue particulièrement difficile.
Les projets peinaient à aboutir, le turnover était très important, la communication était devenue difficile, et la confiance entre les équipes et la direction s’était fortement dégradée.
Au fil des années et des différents choix technologique, l’équipe technique avait accumulé une dette importante au fil des années. Certaines technologies et applications étaient devenues difficiles à maintenir et à faire évoluer. Les nouveaux projets demandaient beaucoup trop de temps et d’investissement : leur coût de développement pouvait atteindre au moins cinq fois ce qu’il aurait dû être dans une situation maîtrisée.
Cette dette n’était d’ailleurs pas uniquement technique.
L’équipe elle-même était en difficulté : Une bonne partie de l’effectif technique était en situation de burn-out. Plusieurs personnes avaient le sentiment de ne pas être écoutées et certaines compétences n’étaient tout simplement pas utilisées au bon endroit.
Dans cette situation, lancer immédiatement une grande refonte technique aurait été une erreur. Il fallait d’abord comprendre ce qui avait conduit jusque-là.
Commencer par écouter et comprendre
Ma première étape a donc été une phase d’audit, à la fois technique et organisationnelle.
Il s’agissait bien sûr d’étudier les applications existantes, leur architecture, leur dette technique et les projets en cours, mais également de prendre le temps d’écouter les personnes qui travaillaient quotidiennement avec ces outils.
Cette seconde partie s’est révélée essentielle.
Certaines difficultés étaient connues depuis longtemps par l’équipe. Des personnes disposaient des compétences nécessaires pour les résoudre ou avaient déjà identifié des pistes d’amélioration, sans avoir réellement eu l’occasion de les mettre en œuvre.
Une des premières actions a donc été de remettre les bonnes personnes sur les bons sujets, en tenant compte de leurs compétences, de leurs appétences et de leur connaissance de l’existant.
L’objectif n’était pas de tout bouleverser : il fallait d’abord redonner à l’équipe la possibilité de travailler correctement.
Reconstruire, mais dans le bon ordre
Une fois cette première phase engagée, il fallait commencer à traiter la dette technique.
L’un des premiers chantiers structurants concernait l’outil auteur, une application centrale permettant de produire les contenus exploités par la plateforme.
Plutôt que de repartir immédiatement dans le développement, j’ai commencé par redéfinir le besoin et établir un cahier des charges. L’objectif était de reconstruire un outil répondant réellement aux usages, tout en créant des fondations suffisamment saines pour éviter de reproduire quelques années plus tard les mêmes difficultés.
Le développement d’un nouvel outil auteur interne a ensuite été lancé.
Une fois ce chantier suffisamment avancé et remis sur de bonnes voies, nous avons pu nous attaquer à un deuxième élément majeur du système : le LMS développé en interne.
Là encore, l’enjeu dépassait largement une simple modernisation technologique. Il fallait progressivement sortir d’une situation où chaque évolution devenait coûteuse et risquée, tout en continuant à faire fonctionner l’activité existante.
Faire communiquer les outils plutôt que multiplier les silos
La modernisation des applications principales ne constituait cependant qu’une partie du travail.
Au fil du temps, l’entreprise avait naturellement adopté différents logiciels et services pour répondre à ses besoins : applications internes, outils commerciaux, CRM et autres services en ligne.
Pris individuellement, chacun pouvait remplir correctement son rôle. Mais lorsqu’ils ne communiquent pas suffisamment entre eux, ce sont les équipes qui finissent par assurer manuellement la circulation de l’information.
J’ai donc également travaillé directement sur ces problématiques d’intégration.
Une partie de mon rôle est restée volontairement très « hands-on » : conception mais également réalisation technique de certaines connexions entre les différents systèmes.
Cela a notamment concerné l’intégration du CRM avec les outils internes, afin que les informations puissent circuler entre les différentes briques du système d’information plutôt que de rester enfermées dans des silos.
Le rôle d’un CTO n’est pas nécessairement de s’éloigner de la technique. Dans certaines situations, comprendre précisément les contraintes et intervenir directement permet au contraire de prendre de meilleures décisions à l’échelle de l’entreprise.
Préparer aussi l’étape suivante : exploiter l’information grâce à l’IA
En parallèle de ces chantiers, j’ai commencé à travailler sur l’intégration de l’intelligence artificielle dans les outils de l’entreprise.
Le besoin était très concret.
Au fil de son activité, l’entreprise produisait et accumulait une quantité importante de documents et d’informations répartis entre plusieurs outils. Cette connaissance existait, mais il était difficile pour une personne d’en exploiter rapidement toute la richesse.
Nous avons donc commencé à travailler sur une approche basée notamment sur le RAG (Retrieval-Augmented Generation).
Le principe consistait à permettre à un système d’IA de rechercher les informations pertinentes au sein de cette documentation avant de construire sa réponse.
L’un des premiers usages envisagés concernait l’équipe Customer Success : lui permettre de s’appuyer beaucoup plus facilement sur la connaissance accumulée par l’entreprise dans ses différents outils pour accompagner les clients.
L’objectif n’était donc pas « d’ajouter de l’IA » parce que la technologie était nouvelle, mais de partir d’une ressource déjà disponible — la connaissance produite par l’entreprise — et de chercher comment la rendre réellement exploitable.
Une transformation technique commence rarement par la technologie
Cette expérience a surtout renforcé une conviction qui guide aujourd’hui ma manière d’aborder les projets informatiques.
Face à une dette technique importante, la tentation est grande de chercher immédiatement la nouvelle architecture, le nouveau framework ou le nouvel outil qui va tout résoudre.
Mais une organisation technique est avant tout constituée de personnes.
Dans cette situation, la première étape n’a donc pas été de réécrire les applications. Elle a été d’écouter l’équipe, de comprendre l’existant et de remettre les compétences au bon endroit.
Ce n’est qu’ensuite qu’il devenait possible de travailler progressivement sur le reste : reconstruction des applications structurantes, réduction de la dette technique, mise en cohérence des différents outils et, enfin, introduction de nouvelles possibilités comme l’intelligence artificielle.
La technologie n’était pas le point de départ de la transformation. Elle en était l’un des moyens.