Un projet numérique quand les équipes métier n’ont pas le temps

Un projet numérique commence parfois par une contradiction assez simple. Les équipes ont besoin d'un nouvel outil pour mieux travailler, mais elles sont déjà trop occupées pour s'investir dans sa construction. Il faudrait prendre du recul, décrire les processus, préciser les règles, imaginer les écrans. Tout cela en continuant à faire tourner l'activité.

Le projet est souhaité. La place dans l'agenda, elle, n'existe pas encore.

Peut-on lancer un projet de logiciel métier sans cahier des charges exhaustif ? Oui, à condition que le prestataire prenne en charge une partie du cadrage fonctionnel et organise l'implication progressive des équipes métier. Le budget, les grandes fonctionnalités et les contraintes doivent être définis ; les détails peuvent se construire au fil des échanges et des essais.

Bon nombre de nos projets, notamment avec le CEA et l'ASNR, fonctionnent dans cette configuration. Les interlocuteurs connaissent très bien leur métier, voient ce qui coince et ont envie que cela change. En revanche, leur demander un cahier des charges exhaustif, ou de bloquer d'emblée une part considérable de leur semaine, revient à ajouter une difficulté à celle qu'ils cherchent à résoudre.

Nous avons donc appris à prendre en charge davantage de travail en amont : comprendre, chercher, proposer, organiser les décisions. Puis à faire évoluer ces propositions avec les équipes, à partir de quelque chose qu'elles peuvent essayer. Nous le faisions déjà avant l'usage de l'IA pour développer, notamment sur Dosima. C'était plus dur. Aujourd'hui, l'IA nous permet de donner beaucoup plus de place à cette manière de travailler.

Un graphe correct, et pourtant illisible

Sur un projet récent, nous devions représenter des systèmes industriels sous forme de graphes. La nature exacte de ces représentations restait à préciser. Le client souhaitait retrouver quelque chose de familier, proche du schéma technique, mais avait du mal à nommer et à décrire ce qu'il avait en tête.

Nous avons commencé par disposer automatiquement les éléments, avec des algorithmes issus du placement des composants dans les circuits intégrés. Le résultat était correct techniquement. Pour les équipes métier, il était illisible : elles ne retrouvaient pas leurs schémas habituels.

Un atelier de deux heures, pendant lequel elles nous ont montré des exemples, a permis de comprendre l'écart. L'agencement attendu traduisait des liens fonctionnels entre les éléments. Ces liens, seuls les experts métier les connaissaient. Une partie de l'information existait dans des documents dispersés, un PDF dans un service, un autre ailleurs. Un algorithme de placement ne pouvait pas reconstituer à lui seul cette lecture du système.

Nous avons alors construit un outil permettant aux équipes de définir leurs propres règles de positionnement. Nous les avons accompagnées pour créer les premiers schémas, ajusté les outils de création et ajouté des aides, dont de la génération automatique dans certains cas.

Le changement était profond, jusque dans l'interface de l'application. Nous sommes passés de l'idée d'un graphe universel affichant tout à des graphes spécifiques, chacun entouré de son contexte et validé par un expert. Aujourd'hui, les équipes se sont emparées du sujet et publient ces schémas à leur rythme, selon leurs besoins.

Cadrer un logiciel métier sans cahier des charges exhaustif

Une équipe métier sait traiter ses dossiers, repérer les exceptions et décider de la suite. Traduire cette connaissance en spécifications représente un travail supplémentaire : expliquer des évidences, mettre des mots sur des habitudes, distinguer les règles métier des contraintes de l'outil actuel.

Nous prenons une partie de ce travail à notre charge. Nous nous documentons, échangeons avec les personnes concernées et cherchons à nous placer dans leur contexte. À quoi sert cette information ? Qu'est-ce que la personne doit pouvoir décider ensuite ?

Aujourd'hui, l'essentiel de notre travail consiste à assimiler le métier et à bien comprendre les fonctionnalités. La rapidité d'implémentation nous permet de consacrer davantage d'efforts à ce qui donnera son utilité à l'outil.

Il faut évidemment que le métier nous réponde, nous corrige et nous explique ce que nous ne pouvons pas deviner. Mais il peut réagir à des propositions que nous avons préparées, plutôt que devoir construire seul toute la description de son futur outil.

Nous ne demandons pas au client d'arriver avec toutes les réponses. Nous organisons le travail pour les construire avec lui.

Concevoir sans décider de chaque détail

Le travail suit généralement trois grandes phases : la conception, une première réalisation, puis la finalisation et les ajustements. La répartition du temps varie selon les projets, mais la réalisation initiale est souvent la plus courte. Comprendre ce qu'il faut construire et l'ajuster à l'usage prennent davantage de place.

En conception, nous cherchons à comprendre le métier et à en déduire les grandes fonctionnalités centrales. Il faudra importer des données, traiter un ensemble d'informations dans le cadre d'un processus, produire des exports, envoyer des notifications. Nous expliquons ce que nous envisageons et vérifions que nous avons compris l'essentiel.

À ce stade, notre équipe découvre encore le métier, et les équipes métier n'ont pas le temps de préciser chaque détail. Nous acceptons donc une certaine souplesse dans la description. Pour un export, par exemple, le choix entre CSV et Excel peut rester ouvert. Pour un traitement, le détail d'une formule ou de l'enchaînement des opérations pourra être précisé ensuite. Les notifications ne sont pas nécessairement toutes définies.

En revanche, nous vérifions que nous disposons des éléments nécessaires à la construction du processus. Si celui-ci dépend d'un service extérieur, il faut savoir si nous pourrons y accéder. Un choix de format peut attendre ; une dépendance inaccessible peut remettre en cause ce que nous proposons.

Une première version pour avoir quelque chose à discuter

Sur un projet relativement simple, ou dans un secteur que nous connaissons bien, un ensemble assez large de fonctionnalités peut arriver d'un coup. Nous avons suffisamment de repères pour construire une première version qui servira de base à la discussion.

Sur un projet très complexe, cette étape produit surtout un socle technique, avec encore peu de fonctionnalités. Celles-ci se construisent progressivement, à mesure que nous affinons la compréhension du métier.

Dans les deux cas, le métier peut commencer à confronter nos propositions à son activité. Comme sur le projet de graphes, nous pouvons revenir sur chaque fonction, l'affiner, et parfois reconsidérer un choix qui paraissait pertinent au départ.

C'est là que nous introduisons beaucoup d'agilité. Nous conservons le cadre des grandes étapes, assez proche d'un cycle en V, avec une conception, une réalisation et une finalisation. Mais les détails se construisent par des échanges et des ajustements successifs, particulièrement dans la dernière phase, et parfois bien plus tôt sur les projets complexes.

Deux moments demandent toujours du temps au métier

Il reste deux moments où les équipes doivent être disponibles. Le premier est le dialogue de conception. Nous faisons des efforts pour comprendre, mais nous avons besoin de personnes qui nous parlent de leur activité. Ce dialogue est inévitable.

D'expérience, il est aussi plutôt agréable pour les équipes lorsqu'elles ont face à elles des interlocuteurs qui comprennent ce qu'elles racontent. Elles parlent de leur travail, de ses difficultés, de ce qu'elles aimeraient améliorer. Dans les configurations que nous avons rencontrées, elles prennent volontiers environ deux heures par semaine pour ces échanges. Le rythme dépend ensuite des sujets à éclaircir et de la nature du projet.

Le second moment est l'affinage et l'appropriation. Il faut manipuler l'outil, essayer les fonctionnalités et les confronter à son activité. La connaissance du métier permet alors de préciser ce qui manque, ce qui convient et ce qui doit changer. Ce temps ne peut pas être entièrement pris en charge par notre équipe : à un moment, les personnes qui vont utiliser l'outil doivent commencer à l'utiliser.

Nous pouvons préparer les propositions et porter le projet. Le temps nécessaire pour s'approprier l'outil appartient toujours aux équipes qui vont s'en servir.

La confiance change la place du projet dans l'agenda

La phase d'affinage arrive souvent après le premier tiers du projet, ou vers sa moitié, selon sa nature. Entre-temps, les équipes se connaissent. Nous avons échangé, proposé des choses, commencé à construire. La confiance s'est installée.

Dans les projets que j'ai accompagnés avec ce fonctionnement, les équipes métier avaient alors presque hâte de tester. L'affinage devient un moment auquel elles ont envie de participer.

Il leur prend du temps. Seulement, ce temps commence à avoir une utilité visible. Elles peuvent agir sur un outil qui existe, apprécier les propositions et en faire évoluer la direction. Leur implication grandit avec leur appropriation.

Au début, Improba porte beaucoup le projet : nous proposons le rythme, préparons les décisions et prenons des initiatives. Les équipes métier se laissent guider. Puis, assez naturellement, à mesure qu'elles prennent l'outil en main, elles prennent davantage la main sur le projet lui-même.

Une équipe qui porte les premières propositions

Un responsable projet senior, expérimenté dans des métiers proches de celui du client, prend des initiatives, propose un rythme et évite les blocages. Il conduit les réunions et les comités de pilotage, en tenant compte des enjeux stratégiques et des relations entre services.

Les responsables technico-fonctionnels prennent chacun en charge un ensemble de fonctionnalités, de leur compréhension à leur réalisation. Puisque le client n'a pas eu le temps de tout détailler, ils se documentent, dialoguent avec lui et cherchent à se placer dans son contexte. Leur responsabilité est de s'assurer que ce qu'ils construisent répond au besoin. C'est le travail que nous évoquions à propos du développeur avec IA.

Un responsable qualité intervient ponctuellement pour guider les revues de code, de sécurité et de performance. Les intervenants extérieurs sont briefés par l'équipe et participent aux échanges selon les besoins. Cette organisation permet de garder le contexte du projet tout en faisant intervenir les compétences nécessaires.

Prévoir l'affinage dans le budget

L'ajustement fait partie du projet dès le départ. Avant l'usage des outils d'IA, nous ajoutions environ 30 % au budget pour absorber cette flexibilité. Aujourd'hui, le temps gagné sur la réalisation nous permet de réserver une part importante du travail à la compréhension du métier et aux ajustements, avec des budgets de projet qui restent comparables à ceux d'avant.

En pratique, chaque ajustement est discuté dans notre équipe et avec le client. Nous estimons son coût et nous examinons ce qu'il apporte, au regard du budget du projet, du calendrier et des autres sujets à traiter. La souplesse repose sur ces arbitrages : tous les ajustements envisageables ne méritent pas nécessairement le même investissement.

On le faisait déjà avant l'IA

Dosima, notre outil de lecture et de validation de dosimètres, a été construit de cette manière. C'était avant que nous utilisions l'IA générative pour produire du code. Comprendre le métier, porter des propositions, puis ajuster l'outil avec les équipes faisait déjà partie de notre pratique.

Mais la réalisation technique absorbait une part importante du temps et du budget. Sur Dosima, les scientifiques du projet consacraient beaucoup de temps à l'implémentation. Nous faisions déjà ces allers-retours, avec moins de latitude pour les multiplier ou approfondir chaque fonctionnalité.

Dans notre pratique actuelle, l'IA produit très rapidement du code et des premières versions de logiciels. Les responsables technico-fonctionnels disposent de moyens pour guider cette production, l'ajuster à ce qu'ils cherchent à construire et en vérifier la qualité dans le cadre fourni par l'entreprise.

Nous pouvons ainsi consacrer davantage de travail à la compréhension du besoin, et revenir plus facilement sur une proposition lorsque l'échange avec le métier en révèle les limites. Sur le projet de graphes, comprendre les liens fonctionnels restait un travail à faire avec les experts du client. L'accélération de la production nous donne davantage de place pour ce travail humain et ses conséquences sur l'outil.

Commencer un projet logiciel par un lot de cadrage

Pour démarrer, le client doit définir un cadre budgétaire et accepter de nous confier cette part de compréhension et de proposition. La confiance compte beaucoup, de part et d'autre. Avec un nouveau client, elle doit pouvoir se construire dans le travail.

Nous proposons donc de fonctionner par lots d'un à deux mois. Un lot 0 sert à la conception, à l'acculturation au métier et à la construction du socle technique. Les lots suivants portent des grandes fonctionnalités dont les détails seront précisés ensemble. Le client s'engage sur un lot, puis sur le suivant. Il paie et reçoit un livrable avant la fin du projet, ce qui lui permet d'apprécier notre travail au fil de la collaboration.

Les documents métier sont aussi précieux au démarrage. Lorsqu'ils peuvent être partagés, nos équipes les étudient avant les réunions pour se familiariser avec le contexte. Nous gagnons beaucoup de temps dans les échanges : les personnes n'ont pas à reprendre toute l'explication depuis le début.

Sur le projet de graphes, le métier a fini par produire ses propres schémas, avec ses règles, au rythme de ses besoins. C'est cette appropriation que nous cherchons à rendre possible, en portant les premières propositions puis en donnant aux équipes les moyens de prendre la main.

Si vous avez un projet que le manque de disponibilité des équipes vous empêche de lancer, parlons du premier lot. Quels besoins faudrait-il éclaircir, quels documents peuvent nous aider, et quelle première réalisation permettrait de commencer à travailler ensemble ?