Retour d'expérience du mois
Créer une application LC/NC pour nos techniciens en intervention Field ServicePar Julien Desgoutte
Retour
Après quelques postes de responsabilité IT au sein de collectivités locales, Julien DESGOUTTE rejoint le secteur privé en 2022 comme Chef de projet et Ingénieur Avant-Vente chez ALDENE, avant de prendre le poste de DSI du groupe Mastergrid basé à Grenoble. Lors de la matinale Low-Code / No-Code organisée par le CRiP le 24 Mars 2026, Julien a exposé les choix effectués pour développer une application No-Code, adaptée aux besoins très spécifiques du Field Service Management dans un milieu industriel.
Mastergrid est un expert des systèmes électriques, nous sommes à la fois constructeurs d’équipements électriques et prestataires de services de maintenance et de rénovation de matériels. Nous fabriquons en France principalement des équipements dédiés à la Haute Tension, comme des disjoncteurs, sectionneurs et opérons également sur les secteurs Moyenne et Basse Tension en fabrication comme en maintenance.
La société a été créée fin 2019 avec 120 collaborateurs, et un chiffre d’affaires d’une 30 M€. Aujourd’hui nous sommes plus de 550 collaborateurs, et notre CA 2025 a dépassé les 120 M€, dont 35% réalisés à l’international.
Cette croissance forte que nous avons vécue en 5 ans a impacté le pilotage de la DSI, parce que nos besoins IT ont évolué, à la fois en raison d’une nouvelle structuration de l’organisation, et à la forte diversification de nos activités liée à notre croissance.
Du fait de notre croissance externe, des entreprises autrefois indépendantes, plutôt des PME, nous ont rejoint petit à petit en apportant chacune ses outils de pilotage d’activité de terrain, de maintenance et de services, souvent construits à la main par les Métiers en mode Excel, le tout sans cohérence les uns avec les autres.
Nous voulions standardiser, normaliser et uniformiser notre SI, développer de nouvelles pratiques et de nouveaux outils, mieux gérer la fiabilité et la sécurité de l’information. Enfin, nous souhaitions centraliser le pilotage, rationaliser la gestion des équipements électriques de nos clients dans un outil renforçant notre efficacité lors des interventions, et sortir enfin de la « culture Excel » mise en place au fil des ans par les opérationnels.
Dans ce contexte, nous avons recherché une solution de Field Service Management (FSM) avec des spécificités qui nous semblaient être standard. Mais cette démarche a été finalement un peu plus compliquée que prévu.
Elles étaient nombreuses ! Nous étions à la recherche d’une solution capable de faire de la planification à la fois de chantiers longs et d’interventions courtes de maintenance, mais aussi de faire de la préparation technique plutôt réalisée au bureau.
Nous avions également une contrainte forte de connectivité de l’application mobile qui serait mise à disposition de nos collaborateurs sur le terrain, qui subissent parfois des contraintes de communication dégradée voire impossible, comme c’est le cas dans les centrales nucléaires. Il était impératif d’avoir une fonctionnalité hors connexion qui doit suffisamment robuste sur l’application mobile.
Pour la maintenance, nous avions déjà des outils de GMAO, mais qui ne géraient pas convenablement les projets longs, et pourtant ce sont les mêmes équipes qui interviennent sur les projets courts ou longs.
Dernier point, nous voulions améliorer la qualité de nos rapports d’intervention, un travail souvent complexe et mal vécu par des opérateurs terrain qui préfèrent consacrer leur temps à réparer les installations de nos clients, plutôt que passer des heures au bureau pour remplir des documents.
En résumé, il nous fallait un outil global pour une planification globale, avec une traçabilité et une uniformisation de nos interventions, et simplifier la collecte des données de nos clients qui influe sur la sécurité et la qualité des interventions effectuées.
Nous avons réalisé un benchmarking de plusieurs solutions du marché, mais au final, aucune ne nous semblait parfaitement adaptée à nos besoins. De plus nous souhaitions limiter notre dépendance à un développement externe, voire à un intégrateur sur le paramétrage ou la customisation du code.
Nous avons donc fait le choix de la solution No-Code proposée par l’éditeur français TimeTonic, aisément paramétrable pour satisfaire nos besoins spécifiques, et capable de s’intégrer facilement avec nos applications existantes comme Sage ou SalesForce.
Comme dans notre équipe de 8 personnes à la DSI, nous ne disposions pas vraiment de compétences en développement, une solution No Code était un bon moyen d’avancer rapidement sur la réalisation.
Le pilotage de ce projet a été assuré par la DSI, comme c’est le cas de tous nos gros projets applicatifs, mais avec la volonté de faire participer les métiers à la conception de la solution, qui nous a amené à mettre en place des citizen developpers.
Enfin, nous avons été intéressés par la souveraineté que nous apporte une solution proposée par un éditeur français comme TimeTonic, hébergée en France.
Nous avons fait le choix de travailler en mode Agile. Durant pratiquement les 12 mois de projet, nous avons mené environ 2 ateliers par mois, en y invitant les Métiers à chaque fois que l’on concevait en No Code les différents modules du FSM, avec l’accompagnement de TimeTonic.
Cette démarche nous a permis d’atteindre un coût total très inférieur à ce que nous aurait coûté un projet basé sur une solution packagée sur étagère, assez complexe à paramétrer pour répondre à nos besoins spécifiques. Pour donner un ordre d’idée, le coût CAPEX estimé est d’environ 75 K€ (hors Opex annuels et ETP internes)
J’en citerais 3 principales. En premier lieu, il a fallu tenir compte de la charge supplémentaire qui portait sur les Métiers. Avec une démarche Agile, ils doivent être très disponibles, et se mettre dans un état d’esprit constructif afin de proposer des idées, de remettre en question parfois des pratiques existantes sur le terrain, mais plus réellement adaptées à nos besoins futurs.
En deuxième lieu, la conduite du changement a nécessité de mettre en place des formations et de concevoir des supports post-déploiement très adaptés pour la mise à disposition des équipes terrain.
J’insisterais pour terminer sur les risques tentateurs lors d’une construction progressive. Je veux parler de la nécessité d’éviter les changements permanents, le besoin de bien tracer et historiser toutes les modifications. Sans cette rigueur, en phase projet, on pourrait avoir tendance à construire, modifier, corriger, et finalement avancer parfois d’un pas en avant, puis de deux pas en arrière sur certaines fonctionnalités. Nous avons fait le choix de s’obliger à produire des versions de façon structurée, en gardant nos objectifs, sprint après sprint.
Dans la phase projet, nous avons utilisé Copilot dans la démarche de co-construction. Cela a structuré notre travail, grâce à l’enregistrement et la transcription par Copilot de tous nos ateliers via Teams, puis la rédaction automatique du compte-rendu. Nous avons également créé un agent Copilot pour résumer nos échanges, rédiger un relevé de décisions soumis au Comité de Pilotage et permettre une interrogation historique à posteriori de toutes les étapes du projet, ce qui nous a permis d’éviter des retours arrières grâce à tous les documents de référence partagés et accessibles.
Au sein de notre application, nous avons intégré une fonctionnalité native de TimeTonic pour prompter des moteurs LLM du marché ou des moteurs internes de TimeTonic, et d’intégrer les réponses dans notre FSM.
Pour donner un exemple, nos collaborateurs terrain prennent beaucoup de photos des plaques signalétiques des composants électriques sur lesquels nous intervenons. Ces photos nous permettent de compléter notre base d’information sur les équipements présents chez chacun de nos clients. Malheureusement il arrive que certaines plaques signalétiques soient partiellement abimées, ou illisibles. Ce que permet l’IA, au-delà d’une banale reconnaissance de caractères (OCR) sur la plaque, est de vérifier la cohérence des informations reconnues, de déduire de certaines caractéristiques la valeur de champs non renseignés ou illisibles, en calculant ces valeurs à partir d’informations recueillies sur des fiches techniques ou en s’appuyant sur les normes auxquelles le composant électrique est supposé respecter.
Pour conclure, travailler avec l’IA a facilité notre gestion de projet et permis de tracer tous les échanges avec les Métiers. Nous sommes garants de l’adéquation entre la demande des Métiers et les fonctionnalités délivrées par l’application.
Et au sein de l’application, l’IA nous a permis d’ajuster les fonctionnalités de notre FMS de manière extrêmement simple. Nous avons pu améliorer se façon significative la qualité des informations sur les équipements électriques de nos clients, et ainsi augmenter notre réactivité et notre qualité de service.
Dans quel secteur d’activité se positionne Mastergrid ?
Mastergrid est un expert des systèmes électriques, nous sommes à la fois constructeurs d’équipements électriques et prestataires de services de maintenance et de rénovation de matériels. Nous fabriquons en France principalement des équipements dédiés à la Haute Tension, comme des disjoncteurs, sectionneurs et opérons également sur les secteurs Moyenne et Basse Tension en fabrication comme en maintenance.La société a été créée fin 2019 avec 120 collaborateurs, et un chiffre d’affaires d’une 30 M€. Aujourd’hui nous sommes plus de 550 collaborateurs, et notre CA 2025 a dépassé les 120 M€, dont 35% réalisés à l’international.
Quels étaient les défis posés à la DSI ?
Cette croissance forte que nous avons vécue en 5 ans a impacté le pilotage de la DSI, parce que nos besoins IT ont évolué, à la fois en raison d’une nouvelle structuration de l’organisation, et à la forte diversification de nos activités liée à notre croissance.Du fait de notre croissance externe, des entreprises autrefois indépendantes, plutôt des PME, nous ont rejoint petit à petit en apportant chacune ses outils de pilotage d’activité de terrain, de maintenance et de services, souvent construits à la main par les Métiers en mode Excel, le tout sans cohérence les uns avec les autres.
Nous voulions standardiser, normaliser et uniformiser notre SI, développer de nouvelles pratiques et de nouveaux outils, mieux gérer la fiabilité et la sécurité de l’information. Enfin, nous souhaitions centraliser le pilotage, rationaliser la gestion des équipements électriques de nos clients dans un outil renforçant notre efficacité lors des interventions, et sortir enfin de la « culture Excel » mise en place au fil des ans par les opérationnels.
Dans ce contexte, nous avons recherché une solution de Field Service Management (FSM) avec des spécificités qui nous semblaient être standard. Mais cette démarche a été finalement un peu plus compliquée que prévu.
Quels étaient vos attentes fonctionnelles ?
Elles étaient nombreuses ! Nous étions à la recherche d’une solution capable de faire de la planification à la fois de chantiers longs et d’interventions courtes de maintenance, mais aussi de faire de la préparation technique plutôt réalisée au bureau.Nous avions également une contrainte forte de connectivité de l’application mobile qui serait mise à disposition de nos collaborateurs sur le terrain, qui subissent parfois des contraintes de communication dégradée voire impossible, comme c’est le cas dans les centrales nucléaires. Il était impératif d’avoir une fonctionnalité hors connexion qui doit suffisamment robuste sur l’application mobile.
Pour la maintenance, nous avions déjà des outils de GMAO, mais qui ne géraient pas convenablement les projets longs, et pourtant ce sont les mêmes équipes qui interviennent sur les projets courts ou longs.
Dernier point, nous voulions améliorer la qualité de nos rapports d’intervention, un travail souvent complexe et mal vécu par des opérateurs terrain qui préfèrent consacrer leur temps à réparer les installations de nos clients, plutôt que passer des heures au bureau pour remplir des documents.
En résumé, il nous fallait un outil global pour une planification globale, avec une traçabilité et une uniformisation de nos interventions, et simplifier la collecte des données de nos clients qui influe sur la sécurité et la qualité des interventions effectuées.
Finalement, quelle solution avez-vous choisie ?
Nous avons réalisé un benchmarking de plusieurs solutions du marché, mais au final, aucune ne nous semblait parfaitement adaptée à nos besoins. De plus nous souhaitions limiter notre dépendance à un développement externe, voire à un intégrateur sur le paramétrage ou la customisation du code.Nous avons donc fait le choix de la solution No-Code proposée par l’éditeur français TimeTonic, aisément paramétrable pour satisfaire nos besoins spécifiques, et capable de s’intégrer facilement avec nos applications existantes comme Sage ou SalesForce.
Comme dans notre équipe de 8 personnes à la DSI, nous ne disposions pas vraiment de compétences en développement, une solution No Code était un bon moyen d’avancer rapidement sur la réalisation.
Le pilotage de ce projet a été assuré par la DSI, comme c’est le cas de tous nos gros projets applicatifs, mais avec la volonté de faire participer les métiers à la conception de la solution, qui nous a amené à mettre en place des citizen developpers.
Enfin, nous avons été intéressés par la souveraineté que nous apporte une solution proposée par un éditeur français comme TimeTonic, hébergée en France.
Comment s’est déroulé le projet ?
Nous avons fait le choix de travailler en mode Agile. Durant pratiquement les 12 mois de projet, nous avons mené environ 2 ateliers par mois, en y invitant les Métiers à chaque fois que l’on concevait en No Code les différents modules du FSM, avec l’accompagnement de TimeTonic.Cette démarche nous a permis d’atteindre un coût total très inférieur à ce que nous aurait coûté un projet basé sur une solution packagée sur étagère, assez complexe à paramétrer pour répondre à nos besoins spécifiques. Pour donner un ordre d’idée, le coût CAPEX estimé est d’environ 75 K€ (hors Opex annuels et ETP internes)
Quelles difficultés avez-vous rencontrées ?
J’en citerais 3 principales. En premier lieu, il a fallu tenir compte de la charge supplémentaire qui portait sur les Métiers. Avec une démarche Agile, ils doivent être très disponibles, et se mettre dans un état d’esprit constructif afin de proposer des idées, de remettre en question parfois des pratiques existantes sur le terrain, mais plus réellement adaptées à nos besoins futurs.En deuxième lieu, la conduite du changement a nécessité de mettre en place des formations et de concevoir des supports post-déploiement très adaptés pour la mise à disposition des équipes terrain.
J’insisterais pour terminer sur les risques tentateurs lors d’une construction progressive. Je veux parler de la nécessité d’éviter les changements permanents, le besoin de bien tracer et historiser toutes les modifications. Sans cette rigueur, en phase projet, on pourrait avoir tendance à construire, modifier, corriger, et finalement avancer parfois d’un pas en avant, puis de deux pas en arrière sur certaines fonctionnalités. Nous avons fait le choix de s’obliger à produire des versions de façon structurée, en gardant nos objectifs, sprint après sprint.
Avez-vous fait appel à l’IA dans votre application ?
Oui, nous avons utilisé l’IA à la fois dans sur la phase projet et dans l’application elle-même.Dans la phase projet, nous avons utilisé Copilot dans la démarche de co-construction. Cela a structuré notre travail, grâce à l’enregistrement et la transcription par Copilot de tous nos ateliers via Teams, puis la rédaction automatique du compte-rendu. Nous avons également créé un agent Copilot pour résumer nos échanges, rédiger un relevé de décisions soumis au Comité de Pilotage et permettre une interrogation historique à posteriori de toutes les étapes du projet, ce qui nous a permis d’éviter des retours arrières grâce à tous les documents de référence partagés et accessibles.
Au sein de notre application, nous avons intégré une fonctionnalité native de TimeTonic pour prompter des moteurs LLM du marché ou des moteurs internes de TimeTonic, et d’intégrer les réponses dans notre FSM.
Pour donner un exemple, nos collaborateurs terrain prennent beaucoup de photos des plaques signalétiques des composants électriques sur lesquels nous intervenons. Ces photos nous permettent de compléter notre base d’information sur les équipements présents chez chacun de nos clients. Malheureusement il arrive que certaines plaques signalétiques soient partiellement abimées, ou illisibles. Ce que permet l’IA, au-delà d’une banale reconnaissance de caractères (OCR) sur la plaque, est de vérifier la cohérence des informations reconnues, de déduire de certaines caractéristiques la valeur de champs non renseignés ou illisibles, en calculant ces valeurs à partir d’informations recueillies sur des fiches techniques ou en s’appuyant sur les normes auxquelles le composant électrique est supposé respecter.
Pour conclure, travailler avec l’IA a facilité notre gestion de projet et permis de tracer tous les échanges avec les Métiers. Nous sommes garants de l’adéquation entre la demande des Métiers et les fonctionnalités délivrées par l’application.
Et au sein de l’application, l’IA nous a permis d’ajuster les fonctionnalités de notre FMS de manière extrêmement simple. Nous avons pu améliorer se façon significative la qualité des informations sur les équipements électriques de nos clients, et ainsi augmenter notre réactivité et notre qualité de service.
Autres articles sur le même thème
Retour d'expérience du mois
Réduire le nombre d’alertes pour améliorer l’efficacité opérationnelle
Vladimir Kharlamoff d'AGIRC-ARRCO
Vladimir Kharlamoff d'AGIRC-ARRCO
Mag #33
Lire l'article
Le retour d'expérience du mois
"Le bilan carbone est une donnée vivante que l’on remet régulièrement à jour"
par Rémi Ollivier, Directeur de programme Transformation chez U TECH
par Rémi Ollivier, Directeur de programme Transformation chez U TECH
Mag #32
Lire l'article
