« Pas besoin d’une fusée Ariane+++ pour des besoins simples »

À la question de savoir ce qu’il attend réellement d’une DSI lorsqu’il porte un besoin métier, François parle d’abord d’accompagnement et d’une réponse adaptée au besoin.

« Pas besoin d’une fusée Ariane+++ pour des besoins simples. »

Cette « fusée Ariane », il ne la voit d’ailleurs pas uniquement dans la solution technique. Elle peut aussi se cacher dans la manière d’organiser le projet.

Faut-il nécessairement créer toutes les EPIC et les User Stories lorsqu’une solution sera livrée quasiment clé en main par un éditeur, avec un guide utilisateur déjà existant ?

Faut-il déployer le même dispositif, les mêmes rôles et les mêmes instances quelle que soit la nature du projet ?

François prend l’exemple d’un projet qui arrive actuellement à son terme. Après la facture de l’éditeur, il estime que l’IT représente probablement l’un des principaux postes de dépenses alors que sa contribution concrète à la solution finale restera proportionnellement plus faible.

Scrum Master, Team Leader, et ainsi de suite…

Il résume la situation avec une image assez parlante : « On se retrouve avec une armée mexicaine qui regarde le métier ramer. » La formule est mordante. Mais derrière elle se pose une vraie question : adaptons-nous toujours le dispositif projet à ce qu’il y a réellement à faire ?

Car à l’inverse, lorsque le besoin nécessite une solution pointue, François attend que les sujets techniques soient anticipés au maximum afin d’éviter les déconvenues en cours de route (ni sous-dimensionner, ni surdimensionner... Mais adapter).

Se sentir accompagné ? « Rarement »

À la question « À quel moment te sens-tu véritablement accompagné ? », la première réponse de François tient en un mot : « Rarement 😅 »

Il nuance évidemment... Il lui arrive de rencontrer des personnes qui s’intéressent réellement au métier et qui sont prêtes à en apprendre suffisamment pour comprendre ce qu’on leur demande.

Mais, selon lui, cela reste presque l’exception. Souvent, chacun reste un peu dans sa bulle et les réunions régulières se terminent par les mêmes questions : « Tout le monde a compris ? Tout le monde sait ce qu’il a à faire ? » Tout le monde répond oui.

Encore faudrait-il s’assurer que tous ces « oui » veulent réellement dire la même chose. Et cette question prend une dimension supplémentaire avec l’internationalisation des équipes et des éditeurs. De plus en plus de projets se déroulent aujourd’hui en anglais. Il ne s’agit alors plus seulement de s’assurer que chacun comprend le besoin de la même manière, mais aussi que les mots utilisés pour l’exprimer recouvrent bien la même réalité pour tout le monde.

Comme le souligne François, cela ajoute finalement « une couche de complexité à la complexité ».

C’est là qu’il attend beaucoup du chef de projet : vérifier aussi souvent que nécessaire que tout le monde « rame bien dans le même sens » et corriger le cap dès qu’une incompréhension apparaît. Parce qu’il est toujours plus simple de modifier quelque chose pendant le développement qu’en recette. Et il est toujours préférable de le découvrir en recette qu’après la mise en production.

Les métiers savent-ils toujours ce qu’ils veulent ?

La question était volontairement directe...

La réponse l’est tout autant : « Non ! Pour sûr ! Haha »

Nous parlons pourtant souvent de « l’expression du besoin » comme si celui-ci existait déjà quelque part, parfaitement défini, et qu’il suffisait au métier de l’écrire correctement. La réalité décrite par François est beaucoup moins simple.

Certaines activités portent derrière elles des dizaines d’années de règles qui n’ont jamais été formalisées. Il faut les retrouver, les centraliser, les challenger et enfin les écrire. Et parfois comprendre au passage pourquoi elles existent encore. Car il y a aussi les habitudes : « On a toujours fait comme ça. »

À force de répéter les mêmes gestes, on finit parfois par ne plus vraiment savoir pourquoi on les fait.

Formaliser un besoin oblige alors à revenir sur des pratiques tellement installées qu’elles ne sont même plus questionnées.

Pour les activités nouvelles, la difficulté est presque inverse. Il n’existe pas d’historique auquel se raccrocher. Le besoin se construit progressivement et certaines règles de gestion évoluent pendant le projet.

Cela ne fait plaisir ni au métier, qui doit parfois revenir sur ce qu’il avait demandé, ni à l’IT, qui pensait disposer d’un besoin stabilisé... Mais il faut l’accepter.

Exprimer un besoin, ce n’est donc pas toujours expliquer à la DSI ce que l’on veut.

C’est parfois commencer par le découvrir soi-même.

Quand le reporting dit que tout va bien

Pour illustrer la question de l’adoption, François revient sur un projet qui l’a particulièrement marqué.

L’objectif était de remplacer des fichiers Excel utilisés pour calculer des provisions par une application dédiée.

Un projet mené avec un éditeur externe sur plusieurs années : expression du besoin, choix de l’éditeur, développements, recettes, mise en service puis évolutions. Les utilisateurs finaux n’avaient pas forcément été embarqués comme ils auraient dû l’être.

Pendant ce temps, les reportings d’avancement circulaient et indiquaient que la situation était globalement maîtrisée. Au pire, « quelques nuages ». Sur le terrain, la perception était différente.

Transcrire dans le nouvel outil toutes les formules existantes s’avérait difficile. Certaines devaient même être corrigées.

François relève surtout un phénomène plus délicat : la crainte de déplaire aux sponsors pouvait parfois prendre le pas sur la réalité constatée par les opérationnels.

Un projet peut donc être vert dans un reporting et beaucoup moins vert pour ceux qui sont en train de le vivre.

L’outil a finalement été mis en production et progressivement adopté par les équipes.

Mais l’histoire se termine par une décision assez pragmatique.

Pour sécuriser durablement son utilisation et sa maintenance, l’entreprise a recruté l’un des prestataires qui avait participé au développement de l’application.

Une manière de conserver en interne la connaissance de l’outil.

François en a surtout retenu quelques écueils à éviter pour les projets suivants.

Mettre en production ne suffit pas

Cette question de la connaissance revient à plusieurs reprises dans ses réponses.

Pour François, une évolution a d’abord plus de chances d’être adoptée si elle répond réellement au besoin des équipes et si les utilisateurs ont été correctement préparés.

Lorsqu’une formation est nécessaire, elle doit avoir lieu avant la mise en production.

Mais l’enjeu ne s’arrête pas à l’adoption.

Si seules quelques personnes savent utiliser un outil, que se passe-t-il lorsqu’elles quittent l’équipe ?

Même question côté DSI lorsqu’un développeur doit, plusieurs années plus tard, intervenir sur une application sans disposer de la documentation lui permettant de comprendre ce à quoi il touche.

François y voit une responsabilité partagée :

• Le métier doit préserver son savoir-faire

• L’IT doit préserver la connaissance technique.

Et lorsque les interlocuteurs changent fréquemment d’un côté comme de l’autre, le manque de formalisation finit par se payer : il faut réexpliquer, reprendre l’historique, retrouver les décisions prises auparavant.

Avec parfois cette impression de recommencer sans cesse et de ne plus vraiment avancer.

Documenter peut sembler chronophage lorsque l’on est dans le rush.

Ne pas documenter les décisions et périmètres utiles peut l’être beaucoup plus quelques années plus tard.

Un projet ne cochera jamais toutes les cases

Sur les arbitrages, François place immédiatement le budget et le planning parmi les contraintes les plus difficiles à tenir. Beaucoup des autres décisions en découlent.

Son approche est assez pragmatique : un projet ne cochera quasiment jamais 100 % des cases prévues au départ... Ce n’est pas forcément un problème.

Renoncer à quelque chose « d’impossible » peut même être la décision qui permettra au reste du projet d’aboutir. À condition que les choix soient partagés et que chacun sache ce qui est non négociable et ce qui peut être ajusté.

D'ailleurs comme le précise François, de ne pas « changer tous les quatre matins d’avis ». Il propose aussi un autre critère d’arbitrage : l’utilité réelle.

Entre une fonctionnalité utilisée cent fois par jour par plusieurs personnes et une autre utilisée peut-être une fois par mois par un seul utilisateur, laquelle doit passer en premier ? Même raisonnement pour cette fameuse « petite fonctionnalité » qui paraît anodine côté utilisateur mais dont le coût de développement est disproportionné.

À un moment, il faut aussi parler d’argent... Un développement a un coût et l’entreprise doit pouvoir justifier ce qu’elle dépense...

Sur ce terrain, François renvoie assez volontiers les deux camps dos à dos.

• Le métier peut formuler des demandes qu’il qualifie lui-même de « fantaisistes ».

• L’IT peut, de son côté, se perdre dans la réunionite, les réorganisations ou l’empilement de couches dont la valeur réelle pour le projet n’est pas toujours évidente.

D’un côté comme de l’autre, la complexité peut finir par devenir sa propre justification.

Deux mondes qui ne se comprennent pas toujours

La dernière partie du questionnaire invitait François à prendre un peu de recul.

Après toutes ces années, qu’a-t-il compris de la relation entre les métiers et la DSI ? « Les relations sont compliquées. »

Le métier ne comprend pas toujours les contraintes informatiques, le fonctionnement des bases de données ou les limites des technologies utilisées. Mais François voit aussi une DSI qui peut parfois, sous couvert d’agilité, s’enfermer dans sa bulle technique et ne plus chercher suffisamment à comprendre le besoin qui se cache derrière la demande.

Entre les deux, le rôle de celui ou celle qui doit faire l’interface devient forcément difficile.

Il faut expliquer, reformuler, dire et parfois redire les mêmes choses... et accepter, comme le dit François, de prendre quelques « coups » au passage.

Il ajoute dans sa réponse une remarque sur l’intelligence artificielle qui m’a forcément fait sourire.

Avec ChatGPT et les autres outils d’IA, chacun risque selon lui de se croire capable de tout comprendre simplement parce qu’il peut désormais poser une question et obtenir une réponse.

La remarque est provocatrice... Mais elle pose une vraie question : accéder plus facilement à la connaissance nous rend-il réellement plus capables de comprendre le métier de l’autre ?

Faut-il parfois savoir être un peu casse-pied ?

La dernière question du questionnaire était simple : Quel conseil donnerais-tu à un chef de projet qui intervient auprès d’un métier ?

François suggère de :

• Sortir un peu des tableaux de suivi du temps passé et du budget pour essayer de comprendre les besoins

• Limiter autant que possible les réunions « administratives »

• Ne pas oublier que lorsqu’un projet IT vient s’ajouter à la production quotidienne, le temps des équipes est précieux.

Il illustre son propos avec un exemple : Sur un projet récent, deux chefs de projet se sont succédé.

Le premier était, selon ses mots, « un brin casse-pied ». Il voulait les éléments rapidement et relançait lorsque cela traînait. Il revendiquait même un certain côté « agressif ».

Le second était plus placide en réunion, mais laissait davantage passer les sujets faute de mordant.

Le constat de François, partagé selon lui par plusieurs personnes côté métier, est finalement assez savoureux : ça avançait davantage avec le premier.

Il ne dit pas qu’il faut devenir en permanence « le chien au milieu du jeu de quilles ».

Simplement que lorsqu’un cahier des charges doit être produit, qu’une recette doit être réalisée ou qu’un compte rendu attend une validation, il faut parfois arrêter d’attendre, relancer, mettre quinze minutes dans l’agenda et traiter le sujet ensemble.

« 15 minutes bien utilisées au début d’un projet, ça peut être plusieurs semaines de gagnées en fin de projet. »

Mon regard

Ce qui m’a frappé dans les réponses de François, c’est qu’elles ne renvoient finalement ni le métier ni la DSI à leurs seules responsabilités.

Le métier ne sait pas toujours exactement ce qu’il veut.

Et lorsqu’il le sait, il ne sait pas forcément l’exprimer.

La DSI, de son côté, peut parfaitement maîtriser ses méthodes, ses outils et son organisation tout en passant à côté de ce que le métier cherche réellement à résoudre.

Entre les deux, nous avons pourtant rarement manqué de méthodes. Nous avons des EPIC, des User Stories, des Scrum Masters, des Team Leaders, des comités, des indicateurs, des reportings…

Malgré tout cela, une réunion peut encore se terminer avec quatre personnes disant « oui, j’ai compris » alors qu’elles n’ont pas compris la même chose. C’est probablement ce paradoxe que je retiens le plus.

À force de professionnaliser la manière de conduire les projets, nous pouvons finir par confondre le dispositif qui accompagne le projet avec le projet lui-même.

La « fusée Ariane+++ » dont parle François prend alors une autre dimension. Elle n’est pas seulement cette solution technique surdimensionnée par rapport à un besoin simple. Elle peut aussi être tout ce que nous construisons autour du projet : des rôles, des processus, des réunions, des livrables… parfaitement légitimes pris séparément, mais dont nous devrions peut-être plus souvent questionner l’utilité au regard du besoin à traiter.

Cela ne signifie évidemment pas qu’il faudrait faire disparaître les méthodes ou les rôles.

Mais peut-être faudrait-il revenir plus souvent à une question très simple : Est-ce que ce que nous sommes en train de faire aide réellement le projet à avancer ?

Et c’est là que le chef de projet « un brin casse-pied » de François devient intéressant. Il n’était peut-être pas le plus confortable.

Il relançait.

Il insistait.

Il allait chercher les réponses.

Mais il faisait avancer les sujets.

Finalement, les réponses de François me ramènent à quelque chose de beaucoup plus élémentaire que nos méthodes : aller voir ce que fait l’autre, lui poser des questions, accepter de ne pas tout comprendre immédiatement et vérifier que derrière les mêmes mots nous parlons bien de la même chose.

Cela demande du temps.

Parfois de la patience.

Et manifestement, de temps en temps, de savoir être un peu casse-pied.

Entre le métier et l’IT, le plus difficile n’est peut-être pas de parler la même langue.

C’est de faire l’effort de comprendre celle de l’autre.

Le Fil de SI

Un espace de réflexion sur les systèmes d'information, les projets et les transformations qui façonnent les organisations.

© 2026 Le Fil du SI — Philippe Viraye

Une idée, une réaction ou l'envie de participer à un Regard croisé ?

Mentions légales · Politique de confidentialité