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

Lorsque je demande à François ce qu'il attend réellement d'une DSI, il parle d'abord d'accompagnement.

Mais aussi d'une réponse technique adaptée au besoin « Pas besoin d'une fusée Ariane+++ pour des besoins simples. »

À l'inverse, lorsque la solution doit être pointue, il attend que les difficultés techniques soient anticipées au maximum. Pas qu'on les découvre lorsque le projet est déjà bien engagé.

Je lui demande alors à quel moment il se sent véritablement accompagné.

Sa réponse me fait sourire : « Rarement 😅 »

Il nuance tout de même.

Il lui arrive de rencontrer des personnes qui s'intéressent réellement au métier, qui cherchent à en apprendre suffisamment pour comprendre le besoin qu'on leur soumet.

Mais, selon lui, cela reste presque l'exception.

Souvent, chacun reste un peu dans sa bulle.

« Tout le monde a compris ? »

La scène parlera probablement à beaucoup de monde.

Une réunion projet se termine.

« Tout le monde a compris ? »

« Tout le monde sait ce qu'il a à faire ? »

Quelques « oui » plus tard, chacun repart.

Le problème, comme le souligne François, c'est que même lorsque le oui est sincère, encore faudrait-il vérifier que tout le monde a compris la même chose.

C'est là qu'il attend beaucoup du chef de projet.

Pas seulement organiser les réunions et distribuer les actions, mais vérifier régulièrement que tout le monde « rame bien dans le même sens ».

Et si ce n'est pas le cas, corriger le cap le plus tôt possible.

Parce qu'une incompréhension détectée pendant le développement sera toujours plus simple à corriger qu'en recette.

Et qu'une incompréhension détectée en recette coûtera probablement moins cher qu'après la mise en production.

Cela paraît presque banal dit comme ça.

Pourtant, combien de fois découvrons-nous tardivement que deux personnes étaient persuadées d'être d'accord alors qu'elles ne parlaient simplement pas de la même chose ?

Les métiers savent-ils vraiment ce qu'ils veulent ?

Cette fois, François ne prend pas beaucoup de précautions : « Non ! Pour sûr ! Haha »

Voilà qui a le mérite d'être clair.

Nous parlons souvent de « l'expression du besoin » comme si le besoin existait déjà quelque part, parfaitement défini, et qu'il suffisait au métier de l'écrire correctement.

Dans la réalité, 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 découvrir au passage pourquoi elles existent. Car il y a aussi les habitudes. « On a toujours fait comme ça. »

À force de répéter les mêmes gestes, on finit par ne plus vraiment savoir pourquoi on les fait. Et remettre à plat un processus oblige parfois à poser une question qui dérange un peu : est-ce encore la bonne manière de faire ?

Sur les activités nouvelles, le problème est différent.

Il n'y a justement pas d'historique auquel se raccrocher. Le besoin se construit alors au fur et à mesure. Certaines règles de gestion évoluent en cours de projet.

Cela ne fait plaisir ni au métier ni à l'IT. Mais il faut bien en tenir compte.

Finalement, exprimer un besoin n'est pas toujours raconter à la DSI ce que l'on veut.

C'est parfois le découvrir soi-même.

Quand le reporting dit que tout va bien

François me raconte alors 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 gros 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.

Et pendant ce temps, les reportings d'avancement circulaient.

Tout allait bien.

Au pire, quelques nuages.

Sauf que sur le terrain, les équipes voyaient autre chose.

Transcrire dans le nouvel outil toutes les formules existantes était compliqué. Certaines devaient même être corrigées.

François pointe surtout un phénomène que je trouve intéressant : la crainte de déplaire aux sponsors pouvait parfois prendre le pas sur la réalité vécue par les opérationnels.

Le projet a fini par aboutir et l'outil a progressivement été adopté.

Mais l'histoire se termine par un détail assez révélateur.

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

Une façon très pragmatique de conserver la connaissance.

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

Mettre en production n'est pas la fin de l'histoire

Cette question de la connaissance revient plusieurs fois dans notre échange.

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é formés avant sa mise en production.

Mais après ? Si trois personnes seulement savent utiliser un outil et que deux d'entre elles partent, que reste-t-il ? Même problème côté DSI. Quelques années plus tard, un développeur devra peut-être modifier l'application. Encore faut-il qu'il dispose d'une documentation lui permettant de comprendre ce à quoi il touche.

François parle ici de responsabilité partagée :

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

• L'IT doit préserver la connaissance technique

Documenter prend du temps. Ne pas documenter en fait parfois perdre beaucoup plus. Lorsque les personnes changent fréquemment, des deux côtés, l'absence de formalisation finit par donner une impression assez désagréable : celle de toujours recommencer et de ne jamais vraiment avancer.

Tout ne mérite pas forcément d'être développé

Lorsque nous abordons les arbitrages, François cite immédiatement le budget et le planning.

Pour lui, ce sont souvent les contraintes les plus difficiles à tenir. Beaucoup des autres arbitrages en découlent. Il part surtout d'un constat pragmatique : un projet ne cochera quasiment jamais 100 % des cases prévues au départ... Ce n'est pas forcément grave.

Il vaut parfois mieux renoncer collectivement à quelque chose d'impossible plutôt que mettre en danger tout le projet. Encore faut-il savoir ce qui est réellement non négociable et ce qui peut être ajusté.

Et éviter, comme il le dit, de « changer tous les quatre matins d'avis ».

François ajoute un autre critère que nous oublions parfois : 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 chose pour cette fameuse « petite fonctionnalité » que l'utilisateur considère comme indispensable mais dont le coût de développement est disproportionné. L'aspect budgétaire pèse dans la balance. Un développement a un coût et l'entreprise doit pouvoir justifier ce qu'elle dépense.

Sur ce sujet, François renvoie d'ailleurs assez volontiers tout le monde dos à dos.

Le métier peut avoir des demandes « fantaisistes ».

Mais l'IT peut aussi se perdre dans la réunionite, les réorganisations ou l'empilement de couches dont la valeur pour l'entreprise n'est pas toujours évidente.

Personne n'a vraiment le monopole de la complexité inutile.

Deux mondes, chacun dans sa bulle ?

Après toutes ces années, je demande à François ce qu'il a compris de la relation entre métiers et DSI.

« Les relations sont compliquées. »

D'un côté, le métier ne comprend pas nécessairement les contraintes de l'informatique, le fonctionnement des bases de données ou les limites des technologies utilisées.

De l'autre, il voit parfois une DSI qui, sous couvert d'agilité, s'enferme de plus en plus dans sa bulle technique sans chercher à comprendre le besoin qui se trouve derrière la demande.

Entre les deux, il faut pourtant bien quelqu'un.

Quelqu'un qui traduise.

Qui explique.

Qui dise et redise parfois les mêmes choses.

Qui accepte aussi de prendre quelques « coups ».

Et François glisse au passage une remarque sur l'IA qui mérite qu'on s'y arrête.

Il craint que chacun finisse par être persuadé de tout comprendre simplement parce qu'il pourra interroger ChatGPT.

La remarque m'a évidemment fait sourire.

Mais le risque qu'il décrit n'est pas complètement absurde : disposer immédiatement d'une réponse ne signifie pas nécessairement avoir compris le métier de l'autre.

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

Je termine en demandant à François quel conseil il donnerait à un chef de projet qui intervient auprès d'un métier.

Il commencerait par sortir un peu des tableaux de suivi du temps passé et du budget.

Comprendre les besoins.

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

Parce que lorsque le projet vient s'ajouter à la production quotidienne, le temps des équipes est précieux.

Et puis il me raconte une dernière histoire.

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. Lorsque cela traînait, il relançait. Il revendiquait même un certain côté « agressif ».

Puis un autre chef de projet a pris la suite.

Plus placide en réunion.

Moins mordant aussi lorsqu'il fallait aller chercher les sujets.

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 « le chien au milieu du jeu de quilles ».

Simplement que lorsqu'un cahier des charges doit être produit, qu'une recette attend ou qu'un compte rendu doit être validé, il faut parfois arrêter d'attendre.

Relancer.

Mettre quinze minutes dans l'agenda.

Et faire le travail 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

J'aime bien le regard de François parce qu'il ne cherche pas vraiment à désigner un coupable.

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

L'IT ne cherche pas toujours suffisamment à comprendre pourquoi on lui demande quelque chose.

Et au milieu, le chef de projet doit essayer de faire avancer tout ce petit monde.

Ce qui m'interpelle surtout, c'est cette question de la compréhension.

Nous avons énormément professionnalisé la gestion des projets.

Des méthodes.

Des outils.

Des indicateurs.

Des instances.

Des rôles de plus en plus précis.

Et pourtant, une réunion peut encore se terminer par quatre personnes disant « oui, j'ai compris » alors qu'elles n'ont pas compris la même chose.

Peut-être cherchons-nous parfois très loin ce qui bloque un projet.

Le témoignage de François me ramène à quelque chose de beaucoup plus élémentaire : 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.

Finalement, 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é