Notes de terrain d'un déploiement à l'échelle de l'entreprise : conversation avec un Forward Deployed Engineer Koddex
Les Forward Deployed Engineers (FDE) de Koddex travaillent au sein des équipes du client pendant des mois, pas des semaines : ils modélisent les données, démêlent les habitudes héritées du passé et s'assurent qu'une nouvelle façon de travailler s'installe durablement.
Dans cette conversation, Thomas Aubert, Head of Revenue chez Koddex, interroge Valentin Houssin, Product & Customer Success Lead, qui assure le rôle de Forward Deployed Engineer sur les déploiements clients. Le projet dont ils parlent est toujours en cours : déployer Koddex comme colonne vertébrale d'ingénierie d'une entreprise industrielle de plus de mille personnes, qui conçoit, fabrique et déploie des systèmes physiques complexes sur les sites de ses clients. En chemin, l'entreprise a abandonné ses outils de boards et une série de produits SaaS ponctuels, réduisant sa facture IT d'environ 30 %.
Le client n'est pas nommé ici et les détails permettant de l'identifier ont été modifiés, mais l'histoire est réelle, et les cicatrices aussi.
1. Le contexte et le point de départ
Thomas Aubert — Avant Koddex, à quoi ressemblait vraiment le quotidien du client ?
Valentin Houssin — Ils avaient déjà une vraie stack : un PLM, un ERP, des outils de boards partout, beaucoup d'Excel, et un produit interne qu'ils avaient développé eux-mêmes pour suivre la documentation produits et pièces. Cet outil interne répondait plutôt bien à ce pour quoi il avait été construit, mais il n'a jamais couvert autre chose que la documentation produits et pièces. Leur équipe interne continuait de l'améliorer, mais évidemment pas au rythme d'une équipe dédiée comme la nôtre. Et il n'avait jamais été pensé pour être réutilisé au-delà de son objectif initial, donc les données qu'il contenait y étaient de fait bloquées.
L'outil de boards, à l'inverse, était partout. Pas seulement en ingénierie. Les ventes, le marketing, les équipes de déploiement, tout le monde construisait des boards, parce que c'est rapide et facile. Le problème, c'est que ces boards reposaient tous sur des données différentes, maintenues à la main, et que la façon d'éditer ces données n'était jamais cohérente d'un board à l'autre. Ce sont des gens brillants, et au quotidien ils arrivaient à éviter les vrais incidents. Mais la qualité du résultat dépendait entièrement de la vigilance des personnes, pas de règles imposées par l'outil.
Et c'est une entreprise qui déploie des systèmes physiques chez ses clients : un même site pouvait afficher un statut différent selon le board que vous regardiez, ou selon les systèmes enregistrés comme installés. À leur taille actuelle, ils le rattrapaient. En grandissant, ça devient intenable.
Thomas Aubert — Y a-t-il eu un déclencheur précis, ou était-ce plutôt une décision stratégique ?
Valentin Houssin — D'après ce que j'ai pu voir, c'était stratégique plutôt qu'un incident isolé. Trois choses ont poussé : ils voulaient arrêter de dépendre d'un outil interne et faire confiance à une solution externe correctement dotée en moyens ; ils voulaient étendre une vraie cohérence et une vraie rigueur de données à toutes les équipes, pas seulement à l'ingénierie ; et il y avait un angle coût très concret. Abandonner l'outil de boards et une série d'autres produits SaaS ponctuels a réduit leur facture IT d'environ 30 %, parce que Koddex pouvait couvrir ces besoins à la place.
Le CEO et le CTO ont porté le sujet directement, et ce sur quoi ils revenaient sans cesse, c'était la rigueur, la cohérence, la traçabilité, combinées à la flexibilité de continuer à modéliser les choses à leur façon.
Thomas Aubert — Plus de mille licences, plusieurs métiers, plusieurs sites. Par où commence-t-on ?
Valentin Houssin — J'étais basé avec l'équipe du siège, là où vivaient la plupart des cas d'usage, avec des équipes plus petites sur des sites à l'étranger. Et il ne s'agissait pas seulement d'ingénierie : les boards étaient utilisés par tout le monde, des ingénieurs aux ventes, au marketing et aux équipes de déploiement. Donc la première étape n'a pas été une migration technique big bang. C'était de parcourir de vrais cas d'usage avec les équipes, de voir comment Koddex y répondait concrètement, d'en choisir une poignée et d'implémenter ceux-là d'abord.
Thomas Aubert — Une surprise dès le début ?
Valentin Houssin — La plus grosse : personne n'arrivait à être totalement aligné sur ses propres processus. À haut niveau, oui, tout le monde vous dira qu'il est aligné. Mais dès que vous creusez un processus précis, vous obtenez de vrais désaccords. Et ça empire à la seconde où vous demandez « comment devrions-nous améliorer ça », parce qu'il ne s'agit plus de décrire l'existant, mais de gens qui défendent leur façon de faire depuis toujours.
2. La réalité du déploiement
Thomas Aubert — Comment avez-vous séquencé le déploiement, big bang ou vague par vague ?
Valentin Houssin — Vague par vague, très délibérément. L'ordre était : d'abord monter une poignée de cas d'usage dans Koddex avec quelques champions internes. Ensuite mettre en place les droits d'accès proprement. Ensuite mettre en place la synchronisation avec les autres outils qu'ils conservaient. En parallèle, continuer à identifier les manques ou les fonctionnalités absentes avec les champions et les construire au fil de l'eau.
C'est seulement après ça que nous avons planifié la migration de l'outil interne dans Koddex et, séparément, la migration des boards existants, puisque l'outil de boards devait être totalement arrêté avant la fin de l'année.
Thomas Aubert — Quelles équipes sont arrivées en premier, et lesquelles ont été les plus difficiles à convaincre ?
Valentin Houssin — Les équipes techniques ont été plus rapides. Elles voyaient plus facilement les avantages de Koddex, ça parlait leur langage. Les équipes business, c'est-à-dire les ventes, le marketing, les profils plus opérationnels, ont été plus difficiles. Certaines ont compris vite dès qu'elles ont vu l'outil en action, mais globalement il y avait une vraie peur : Koddex est un produit jeune, donc la peur du « produit nouveau, non éprouvé » se superpose à la peur ordinaire du changement. Le change management, ici, est une part réellement importante du travail, pas un détail de fin de projet.
Thomas Aubert — Donne-moi une histoire concrète de résistance.
Valentin Houssin — Celle qui m'a marqué : quelqu'un m'a dit, en substance, « vous (l'équipe IT du client) ne nous avez pas demandé ce dont nous avions besoin, vous nous avez juste donné Koddex en nous disant que ça résoudrait nos problèmes ». C'est une critique légitime si c'est comme ça que ça atterrit.
Ce qui a réellement retourné la situation, c'est une démo en direct sur leurs vraies données, une discussion de leurs besoins un par un, et — cette partie a compté davantage que la démo elle-même — le fait de leur demander pourquoi ils faisaient les choses de cette façon au départ, puis de travailler avec eux pour faire réellement évoluer le processus, au lieu de simplement numériser l'ancien.
Thomas Aubert — Où s'arrête « déployer un outil » et où commence « changer la façon de travailler des gens » ?
Valentin Houssin — Honnêtement, nous sommes en plein dedans en ce moment. Le change management n'est pas terminé. Mon attente sincère, c'est que ce sera plus difficile avec les personnes sur le terrain, des profils opérationnels globalement moins à l'aise avec les outils informatiques, qu'avec les personnes du siège déjà habituées à des logiciels structurés.
Thomas Aubert — Y a-t-il eu un moment où tu t'es dit « ça ne va pas marcher » ?
Valentin Houssin — Oui. Il y a eu une période où j'ai eu le sentiment qu'ils ne s'aligneraient jamais sur un processus partagé clé, et sans cet alignement nous ne pouvions avancer ni sur l'intégration ni sur la modélisation. Modéliser dans Koddex exige un accord sur ce qu'est réellement le processus. Si le client n'arrive pas à s'accorder en interne, vous êtes bloqué avant même d'avoir ouvert l'outil.
3. Exigences techniques et métier
Thomas Aubert — Quelles exigences du client ont réellement fait évoluer le produit lui-même ?
Valentin Houssin — Deux, très clairement. Nous avons accéléré notre roadmap sur les dashboards précisément pour qu'ils puissent abandonner leur outil de boards et gagner davantage d'adhésion côté utilisateurs. Les dashboards ont un véritable effet « wow » qu'un simple remplacement de tableur n'obtient jamais. Et nous avons ajouté les notifications pour soutenir des modes de travail plus collaboratifs, ce qui n'était pas une priorité aussi forte avant ce déploiement.
Thomas Aubert — Comment avez-vous géré la migration des données existantes : exigences, nomenclatures, historique de modifications ?
Valentin Houssin — Le plus dur n'était pas la donnée elle-même, c'était de comprendre d'abord leur produit interne. Les gens en avaient fait un usage détourné, en forçant discrètement leur propre processus dans un outil qui n'avait pas été construit pour ça, avec des conventions informelles, humaines, que personne n'avait documentées.
Nous avons dû nous asseoir avec les collaborateurs, comprendre pourquoi ils le détournaient ainsi, quel besoin ce détournement servait réellement, puis trouver comment répondre correctement à ce même besoin dans Koddex plutôt que de simplement reproduire le contournement.
Thomas Aubert — Comment garantir la cohérence des données entre des équipes qui ne partagent ni le vocabulaire ni les priorités ?
Valentin Houssin — La modélisation de Koddex est à la fois rigoureuse et flexible. Les équipes peuvent modéliser exactement comme elles en ont besoin, rien ne leur est imposé par défaut. C'est vraiment très bien, parce que rien n'est gravé dans le marbre. Mais ça a un coût réel : les gens doivent d'abord s'asseoir et s'aligner entre eux, et la modélisation demande un minimum de culture de la modélisation. Ce qui, pour être honnête, est la partie facile pour nous, nous savons former rapidement là-dessus. La partie difficile, c'est l'alignement.
Un exemple concret : les définitions d'« article », de « produit » et de « pièce » n'étaient pas totalement cohérentes entre la production, les ventes et les équipes produit. Les mêmes mots, des sens différents selon la personne interrogée.
4. Où en est-on aujourd'hui
Thomas Aubert — Qu'est-ce qui a changé de façon mesurable à ce stade ?
Valentin Houssin — Je vais être direct : l'intégration et la migration ne sont pas totalement terminées, donc je n'ai pas de chiffre avant/après propre à vous donner, et je préfère ne pas en inventer un. Ce que je peux dire concrètement : ils ont déjà migré l'essentiel de leur QMS, l'essentiel de la documentation de leur architecture IT, certains référentiels transverses, un système complet de suivi des sites clients, et beaucoup d'autres cas d'usage. Ce sont de vrais gains, déjà en production, même si le déploiement global n'est pas achevé.
Note de la rédaction : la migration principale, le transfert des données de l'outil interne vers Koddex, est toujours en cours. C'est là que l'impact le plus important est attendu.
Thomas Aubert — Quel retour t'a le plus marqué, positif ou négatif ?
Valentin Houssin — Du côté difficile : les concepts de « modèle » et d'« item » ne sont pas toujours intuitifs, et l'interface n'est pas encore aussi fluide que celle des leaders de catégorie comme Monday ou Notion. C'est un retour légitime, et c'est le compromis assumé d'un outil construit pour la rigueur plutôt que pour la seule facilité de première prise en main.
Thomas Aubert — Que peuvent faire les équipes aujourd'hui qu'elles ne pouvaient tout simplement pas faire avant ?
Valentin Houssin — L'exemple le plus clair est le projet de déploiement lui-même. Les ventes vendent un système à installer et font signer le contrat. L'équipe de déploiement définit ensuite l'exécution réelle : quels systèmes installer, quelles pièces tierces acheter, quels travaux de préparation du site, etc. Puis l'équipe de maintenance prend le relais.
Avant, ces trois équipes regardaient de fait trois versions différentes de la vérité. Aujourd'hui, elles peuvent toutes regarder le même projet, à n'importe quel stade, et c'est toujours la même donnée sous-jacente. Ce n'est pas un gain de vitesse. C'est quelque chose qui n'était tout simplement pas possible avant.
« Avant, ces trois équipes regardaient de fait trois versions différentes de la vérité. Aujourd'hui, c'est toujours la même donnée sous-jacente. »
5. Leçons et recul
Thomas Aubert — Si tu devais refaire ce déploiement demain, que ferais-tu différemment ?
Valentin Houssin — Je définirais un plan étape par étape beaucoup plus clair dès le départ : ce qui doit se passer, pour quand, par qui, ce que nous attendons exactement du client à chaque étape, et quand. Je planifierais les sessions d'apprentissage de façon volontaire au lieu de les caser de façon réactive. Et je définirais un plan d'onboarding progressif clair avec le client dès le premier jour, au lieu de construire cette structure au fil de l'eau.
Thomas Aubert — Que t'a appris ce projet sur ce qui fait réussir ou échouer l'adoption ?
Valentin Houssin — Deux choses, vraiment. Un : le vrai succès vient du fait de prouver rapidement que Koddex va améliorer quelque chose de précis pour eux. Une fois que les gens ont vu cette preuve, ils sont prêts à faire l'effort. Deux : l'alignement des équipes n'est pas optionnel. Koddex implémente des processus, donc si le processus lui-même n'est pas défini et validé, il n'y a rien de solide à modéliser.
Thomas Aubert — Que dirais-tu à un VP Engineering d'une entreprise d'environ 1 000 personnes qui hésite ?
Valentin Houssin — Ça demande un effort réel, mais le retour arrive vite. Commencez par identifier un vrai point de douleur et prouvez, sur un petit cas d'usage, que Koddex le résout. N'essayez pas de vendre toute la vision dès le premier jour. Et évitez la tentation de tout migrer d'un coup. Allez étape par étape. Toutes les équipes qui ont voulu sauter cette étape l'ont regretté.
À retenir
Le dossier économique était réel. Consolider les outils de boards et les produits SaaS ponctuels dans Koddex a réduit la facture IT du client d'environ 30 %.
Le séquencement compte plus que le périmètre. Le déploiement s'est fait vague par vague, en démarrant par une poignée de cas d'usage réels et quelques champions internes plutôt que par une migration big bang.
L'obstacle le plus dur n'était pas technique. C'était d'amener les équipes à s'aligner sur leurs propres processus, parce que Koddex modélise des processus et ne peut pas modéliser un désaccord.
La preuve débloque l'adoption. Une preuve précoce et concrète sur un point de douleur précis est ce qui finance l'effort que les équipes devront fournir ensuite.
Le gain le plus durable est structurel. Les ventes, le déploiement et la maintenance travaillent désormais sur une seule version de la vérité au lieu de trois.
