À quoi sert un client dans la vie d’un projet IT ?

À quoi sert un client dans la vie d’un projet IT ?

C’est une question que je me pose régulièrement, et peut-être que vous aussi : à quoi sert vraiment un client dans un projet ?

Non, je ne parle pas du rôle évident de « payer la facture ». Je parle de son rôle concret, quotidien, au cœur de la mécanique d’un projet. Est-il un sponsor engagé, un chef d’orchestre… ou simplement un spectateur grincheux ?

Dans un projet IT, il y a de nombreux rôles, les prestataires se mêlent aux employés du client. Je vois trop souvent des soucis de communication, de clarté des rôles, des responsabilités non définies, finalement, un manque de cohésion.

Exemple récent : en pleine rédaction d’un ARD, le client s’énerve parce que des points critiques n’avancent pas. Problème : ces points relevaient de ses experts sécurité et infrastructure. Pas du chef de projet, pas de moi, pas de l’équipe technique. Et pourtant, c’est moi qui devrais relancer, suivre, justifier Mon rôle est de concevoir une architecture et de la faire valider, pas de courir après les experts sécurité du client. Si eux n’agissent pas, qui doit les relancer ? Certainement pas l’architecte.

Le problème : un rôle flou, parfois absent

Dans de nombreux projets, le client donne l’impression de déléguer absolument tout. Il ne gère pas, il observe de loin. Son rôle le plus visible ? La réunion où il exprime son mécontentement.

Il y a derrière cette posture plusieurs soucis. Les attentes en matière de suivi ne sont définies clairement dès le départ du projet. On parle beaucoup de gestion de projet, mais qui prend la responsabilité de la coordination globale côté client ?
Derrière cela se cache une réalité paradoxale : beaucoup de blocages viennent de son propre camp.

L’équipe projet se retrouve à effectuer le travail de coordination que le client aurait dû porter. Rôles inversés.

Autre scène : je pose une question fonctionnelle au client. Sa réponse ? « Voyez avec les développeurs. »
Les mêmes développeurs qui attendaient… une validation du client. On appelle ça le ping-pong fonctionnel. Malheureusement, ce sport ne fait pas avancer les livrables.

Soyons honnêtes : parfois, nous aussi côté prestataire, on se cache derrière des process pour éviter une décision. Le client a ses défauts, mais il n’est pas seul à bord.

Alors, à quoi sert un client ?

Est-il un sponsor financier, qui signe les chèques et rien d’autre ?
Est-il un chef d’orchestre, qui donne le tempo et coordonne ses musiciens ?
Est-il un arbitre, qui tranche les dilemmes fonctionnels quand personne n’ose décider ?
Ou croit-il que son rôle se limite à « mettre la pression » ?

Typologie des clients

En pratique, j’ai rencontré cinq grands profils de clients. Voyez si vous les reconnaissez…

1. Le Spectateur

• Description : Toujours présent en réunion, caméra coupée, micro muet… sauf pour dire « je ne suis pas satisfait ».
• Signature : « Je ne comprends pas pourquoi ça n’avance pas… »
• Problème : Distant, il attend que les choses se fassent toutes seules, puis s’étonne que ça ne marche pas.
• Conséquence : Le projet avance… mais en zigzag, faute de cap.

2. Le Contrôleur

• Description : Il ne fait rien directement, mais il commente absolument tout. Le PowerPoint est trop bleu, la réunion trop longue, la livraison trop courte.
• Signature : « Pouvez-vous me refaire trois variantes de la même chose ? On verra laquelle je valide. »
• Problème : Il croit que mettre la pression, c’est piloter.
• Conséquence : Épuisement de l’équipe, inflation de slides, zéro décision claire.

3. Le Facilitateur (l’espèce rare)

• Description : Il tranche vite, mobilise ses experts, ouvre des portes. Quand il est là, tout le monde respire.
• Signature : « Ok, je prends la décision, on avance. »
• Problème : Il est trop rare. Souvent affecté par un phénomène d’extinction naturelle dans les grandes organisations.
• Conséquence : Quand on en trouve un, on ne veut plus le lâcher.

4. Le Sponsor fantôme

• Description : On sait qu’il existe (quelqu’un a signé le budget, non ?), mais personne ne l’a jamais vu.
• Signature : silence radio complet
• Problème : Son absence crée un vide : personne n’ose trancher.
• Conséquence : Le projet s’auto-gère… jusqu’à ce qu’un jour il réapparaisse pour dire : « Mais ce n’est pas ce que j’avais demandé. »

5. Le Caméléon

• Description : Un jour spectateur, le lendemain contrôleur, parfois facilitateur… mais jamais au bon moment.
• Signature : « Oui, mais là, ce n’est plus ma priorité. »
• Problème : Il change de rôle selon l’humeur ou la météo.
• Conséquence : L’équipe ne sait jamais à qui elle a affaire.

Le client est-il formé à son rôle ?
On forme les chefs de projet, les architectes, les devs… mais jamais les clients. Peut-être qu’une partie du problème vient de là. Peut-être faudrait-il un jour inventer une ‘formation sponsor IT 101’ : savoir trancher, mobiliser, décider.

Le client doit-il être un expert technique ou un simple décideur ?

Certains veulent redevenir techniciens alors qu’ils n’ont plus les mains dedans depuis des années. D’autres se désengagent totalement.

Il faut accompagner, proposer des solutions, montrer le pour et le contre pour lui permettre un arbitrage éclairé.

Qui est responsable du succès du projet ?
Est-ce le prestataire, qui exécute ? Le client, qui sponsorise ? Ou les deux ?
Un projet échoué est toujours attribué au prestataire, rarement au client. Mais est-ce juste ?

Ce que devrait être un client

Un bon client, c’est :

• Celui qui arbitre rapidement les choix fonctionnels, même si ce n’est pas confortable.
• Celui qui mobilise ses experts internes, car personne d’autre ne peut le faire.
• Celui qui facilite, qui ouvre des portes, qui débloque des situations.
• Celui qui porte le projet dans son organisation, politiquement et opérationnellement.

Néanmoins, côté prestataire, des choses sont à faire pour que tout se passe bien :

• Clarifier les responsabilités dès le départ (un tableau RACI, ça a l’air bureaucratique, mais ça évite bien des conflits).
• Rappeler régulièrement les rôles quand la tentation de tout déléguer refait surface.
• Remonter les blocages de façon transparente, écrire noir sur blanc quand une action attendue dépend du client.
• Éduquer doucement, en expliquant que son implication n’est pas une faveur : c’est une condition de réussite.

La vérité, c’est que sur un projet, nous sommes tous sur le même terrain, on joue ensemble la partie, dans la même équipe contre les écueils inhérents à tout projet IT. Un projet ne se fait ni sans, ni contre mais avec le client. Et ce « avec » implique bien plus que d’assister à quelques réunions.

Et si, finalement, le rôle d’un client n’était pas seulement de commander un projet… mais aussi de le faire réussir ?

Un projet IT n’est pas un match où le client reste en tribune VIP à distribuer des cartons rouges. C’est un jeu collectif : si on marque, c’est ensemble ; si on perd, c’est ensemble.

Et vous, comment est votre client ?