Nommer un responsable finance, commercial ou opérations pour piloter un projet IT paraît logique : il connaît l’entreprise, ses processus et les futurs utilisateurs. Le problème commence lorsqu’on lui confie cette mission « en plus » de son poste, sans retirer aucune responsabilité opérationnelle ni définir son pouvoir de décision.
Comme nous l’expliquions déjà dans notre article sur le pilotage d’un projet IT sans DSI, l’absence de direction informatique permanente n’est pas le vrai risque. Le risque est de lancer un projet sans véritable direction côté client.
La promesse qu’on entend partout : votre meilleur opérationnel pilotera le projet
Le discours semble cohérent. Un responsable métier connaît les règles de gestion, les habitudes des équipes, les contraintes clients et les exceptions que le cahier des charges ne documente jamais complètement. Il devrait donc pouvoir coordonner le déploiement d’un ERP ou d’un CRM.
L’éditeur ou l’intégrateur fournit par ailleurs son propre chef de projet. Celui-ci organise les ateliers, produit un planning et rend compte de l’avancement. Le manager interne n’aurait alors qu’à répondre aux questions, réunir les utilisateurs et valider les livrables.
Cette organisation promet trois avantages :
- éviter de recruter un chef de projet supplémentaire ;
- conserver les décisions au plus près des métiers ;
- ne pas ajouter un nouvel intermédiaire entre la direction et le prestataire.
La promesse n’est pas absurde. Elle confond cependant quatre fonctions différentes : sponsor, responsable métier, chef de projet client et chef de projet prestataire.
Ce qui est vrai : la responsabilité métier doit rester dans l’entreprise
Un projet ERP ou CRM ne peut pas être entièrement délégué à un prestataire. Quelqu’un, dans l’entreprise, doit expliquer comment une commande est validée, qui peut modifier un tarif, quelles données doivent être reprises et quelles exceptions restent acceptables.
Ce responsable métier apporte ce qu’aucun consultant externe ne peut décider seul :
- la priorité réelle entre les demandes des services ;
- les règles qui doivent être conservées ou remises en cause ;
- les compromis acceptables pour les utilisateurs ;
- la définition d’un résultat exploitable par l’entreprise.
Le sponsor joue un autre rôle. Il maintient le projet aligné sur l’objectif économique, débloque les ressources et tranche les décisions qui dépassent l’autorité du chef de projet. L’Association for Project Management, dans sa définition du sponsorship, distingue clairement cette responsabilité de la gestion quotidienne du projet : le sponsor reste comptable de la validité du dossier d’investissement et des bénéfices attendus.
Le manager interne est donc indispensable. Il peut être propriétaire du processus métier, référent des utilisateurs ou sponsor délégué. Mais cette légitimité métier ne le transforme pas automatiquement en chef de projet disponible, outillé et habilité à challenger un intégrateur.
Ce qui est faux, ou seulement vrai sous conditions
Connaître le métier ne suffit pas à diriger la livraison
Le chef de projet client ne se contente pas de convoquer des réunions. Il maintient le périmètre, vérifie les dépendances, prépare les arbitrages, suit les risques et conserve la preuve des décisions. Il doit aussi relier les engagements commerciaux du prestataire aux livrables réellement testables.
Ces activités entrent rapidement en concurrence avec le poste principal du manager. Lorsqu’un client important appelle, qu’une clôture comptable approche ou qu’un incident opérationnel survient, le projet passe après l’exploitation. Ce choix est rationnel à court terme, mais il laisse les décisions en attente et permet aux difficultés de s’accumuler.
Le chef de projet de l’intégrateur ne remplace pas celui du client
Le prestataire pilote sa propre production : consultants mobilisés, paramétrages, développements, budget consommé et calendrier contractuel. Le client doit, lui, défendre l’usage futur, la cohérence entre services, la qualité des données et les conditions d’acceptation.
Demander au même acteur de proposer une solution, d’estimer son travail et de déterminer seul si le résultat est acceptable supprime un niveau de contradiction utile. Cela ne suppose aucune mauvaise intention du prestataire : ses responsabilités ne sont simplement pas celles de l’entreprise cliente.
Une seule personne peut cumuler les rôles, mais pas implicitement
Le guide britannique Implementing functional standards: a guide for senior leaders in organisations rappelle une distinction utile : les standards définissent des rôles, pas nécessairement des postes. Une même personne peut donc porter plusieurs responsabilités, à condition qu’elles soient explicites dans sa fiche de mission et dans ses objectifs.
Le cumul peut fonctionner si le périmètre reste contenu, si les responsabilités habituelles du manager sont effectivement allégées, si son autorité d’arbitrage est formalisée et si une autre personne contrôle les estimations et les preuves de recette.
Sans ces conditions, le titre de « chef de projet interne » devient surtout une étiquette apposée sur un responsable métier déjà saturé.
| Rôle | Question à laquelle il répond | Livrable attendu |
|---|---|---|
| Sponsor dirigeant | Pourquoi investissons-nous et que faut-il trancher ? | Mandat, priorités et décisions d’escalade |
| Responsable métier | Comment le processus doit-il fonctionner ? | Règles de gestion et critères d’acceptation |
| Chef de projet client | Comment maîtriser la livraison ? | Planning, risques, décisions et suivi des changements |
| Chef de projet prestataire | Comment produire la solution promise ? | Configurations, développements, documentation et preuves |
Ce que ça coûte quand on y va sans préparation
Le premier coût n’apparaît pas forcément sur la facture du logiciel. Il se manifeste dans les décisions retardées, les ateliers répétés et les demandes contradictoires envoyées au prestataire.
| Symptôme visible | Cause réelle | Conséquence |
|---|---|---|
| Les ateliers avancent, mais rien n’est validé | Personne n’a l’autorité ou le temps de trancher | Le prestataire travaille sur des hypothèses |
| Les demandes supplémentaires se multiplient | Le périmètre initial n’est pas tenu côté client | Le budget devient une succession d’avenants |
| Le manager métier répond entre deux urgences | Son activité habituelle n’a pas été réorganisée | Les décisions arrivent trop tard pour être peu coûteuses |
| La recette est repoussée en fin de projet | Aucun responsable ne prépare les scénarios de test | Les anomalies sont découvertes avant la mise en production |
| Les décisions restent dans les e-mails | Aucun registre commun n’est maintenu | Les désaccords contractuels deviennent difficiles à instruire |
Une autre dépendance apparaît après le déploiement : l’intégrateur reste le seul à connaître les arbitrages, les contournements et les limites de la solution. L’entreprise possède le logiciel, mais pas complètement son historique de décision.
Cette situation alimente également la dette technique. Des interfaces provisoires, des imports manuels ou des règles codées rapidement restent en place parce qu’aucun responsable côté client ne porte leur remplacement. Le projet est officiellement terminé, mais son coût continue de croître dans l’exploitation.
Le choix du mode de déploiement peut limiter certains risques, à condition d’être relié à la capacité réelle de pilotage. Notre comparaison entre big bang, pilote et lots métiers aide à choisir un rythme compatible avec les ressources internes.
La façon raisonnable d’y aller
1. Faire nommer le sponsor par la direction
Le dirigeant signe un mandat de projet tenant sur une page. Ce document précise l’objectif économique, les exclusions, le budget soumis à arbitrage, les décisions que le chef de projet peut prendre et les sujets qui doivent remonter au sponsor.
Le livrable n’est pas un organigramme décoratif : c’est une règle de décision utilisable lorsque deux directions demandent des priorités incompatibles.
2. Séparer explicitement métier, pilotage et réalisation
La direction produit une matrice RACI — responsable, approbateur, consulté et informé — pour les principaux livrables : processus cible, reprise des données, interfaces, recette, formation et mise en production.
Chaque livrable doit avoir un approbateur unique. Une validation « par le groupe projet » crée une responsabilité collective dans laquelle personne ne décide réellement.
3. Organiser le délestage du responsable interne
Le manager désigné prépare avec son supérieur un plan indiquant les activités opérationnelles déléguées, suspendues ou reprises par un collègue. Le livrable attendu est une liste nominative des responsabilités transférées, pas une déclaration selon laquelle « le projet sera prioritaire ».
Si aucune activité ne peut quitter son agenda, il doit rester responsable métier plutôt que recevoir artificiellement la responsabilité complète du pilotage.
4. Installer des preuves de pilotage avant les ateliers
Le chef de projet client crée dès le cadrage :
- un planning associé à des livrables vérifiables ;
- un registre des risques, hypothèses, incidents et dépendances ;
- un journal des décisions avec leur auteur ;
- un registre des demandes de changement et de leurs impacts ;
- une stratégie de recette reliée aux règles métier.
Ces documents permettent au dirigeant de décider à partir de faits, pas d’un pourcentage d’avancement déclaré par le prestataire.
5. Maintenir un contradicteur côté client
Un chef de projet externe ou une DSI partagée peut vérifier les estimations, préparer les arbitrages, contrôler les dépendances et organiser la recette sans se substituer au responsable métier.
Ce rôle doit rester distinct de la production facturée par l’intégrateur. Selon la complexité et les compétences disponibles, le bon dispositif peut être interne, indépendant ou partagé. Nous avons détaillé ces options dans notre comparaison entre DSI partagée, freelance et intégrateur.
Lundi matin, la direction peut déjà demander quatre livrables : le mandat du sponsor, la répartition des rôles, le plan de délestage du responsable métier et le premier journal des décisions. Leur absence est un signal plus utile qu’un planning rempli de dates.
Notre position chez D1 Consulting
Une PME n’a pas nécessairement besoin d’une DSI permanente pour chaque projet. Elle a en revanche besoin d’une direction de projet côté client, avec une autorité identifiable, des décisions traçables et des livrables contrôlables.
Notre offre de Direction de projet IT et DSI partagée couvre le cadrage, le pilotage des prestataires, la préparation des arbitrages, la recette et la conduite du changement. Nous travaillons avec le responsable métier interne : notre objectif n’est pas de lui retirer la maîtrise du projet, mais d’éviter qu’il porte seul deux fonctions incompatibles avec son agenda.
👉 Réservez un diagnostic gratuit de 30 minutes pour clarifier vos rôles, vos livrables et le dispositif de pilotage à mettre en place avant le prochain engagement fournisseur.
