Quels sont les rôles clés d’une équipe de projet TI ?

Un manufacturier de la Beauce lance l’implantation de son ERP. Le vice-président finances « parraine » le projet, mais n’assiste à aucun comité. Le directeur TI pilote, conçoit et teste en même temps. Six mois plus tard, personne ne sait qui a approuvé la portée ni qui représente les utilisateurs de l’entrepôt. Le problème n’est pas le logiciel : ce sont les rôles.

Les chiffres cités proviennent d’études publiques (Gartner, PMI, Panorama Consulting) et décrivent des tendances de marché, pas la situation de votre projet.

Selon Gartner, plus de 70 % des initiatives ERP récemment implantées n’atteindront pas pleinement leurs objectifs d’affaires initiaux d’ici 2027, et jusqu’à 25 % échoueront de façon catastrophique, le plus souvent par manque d’engagement de l’équipe de direction.

Quels sont les rôles clés d’une équipe de projet TI et pourquoi les définir ?

Une équipe de projet TI repose sur neuf rôles clés : le promoteur, le directeur de projet, le PCO, l’architecte de solution, l’analyste d’affaires, l’expert en progiciels, le développeur, le responsable des infrastructures et le responsable de la gestion du changement. Un rôle se définit par ses tâches et ses responsabilités, pas par un titre. Chaque membre peut en cumuler plusieurs, à condition que chacun soit nommé et assumé.

Définir les rôles n’est pas un exercice bureaucratique. Gartner cite la division floue des responsabilités parmi les causes directes de retards, de dérive de portée et de dépassements budgétaires. Un rôle sans titulaire, c’est une décision que personne ne prend.

Les repères chiffrés à garder en tête :

• Selon Gartner, 75 % des stratégies ERP ne sont pas fortement alignées sur la stratégie d’affaires globale, ce qui alimente la confusion et des résultats décevants.
• Selon le rapport Pulse of the Profession 2025 du PMI (2 254 professionnels sondés), seuls 18 % des professionnels de projet démontrent une forte acuité d’affaires ; ceux-ci atteignent les objectifs d’affaires dans 83 % des cas, contre 78 %, et respectent le budget dans 73 % des cas, contre 66 %.
• Toujours selon le PMI (2025), 96 % des répondants jugent la gestion des parties prenantes importante ou très importante, la compétence la plus consensuelle du sondage.
• Selon le rapport ERP 2026 de Panorama Consulting, plus du quart des organisations ont dépassé leur budget, les besoins technologiques imprévus en étant la cause principale.

Qui gouverne le projet : le promoteur, le directeur de projet et le PCO ?

Trois rôles assurent la gouvernance : le promoteur, qui obtient les ressources et répond des bénéfices ; le directeur de projet, qui livre la solution dans la portée, l’échéancier et le budget ; et le PCO, qui fait vivre les processus de gestion et prépare la reddition de comptes. Quand l’un des trois manque, les deux autres compensent mal.

Le promoteur. Il obtient de l’organisation les ressources humaines, matérielles et financières, et il est l’ambassadeur du projet auprès de la haute direction. Il participe aux décisions majeures, se fait le champion des transformations et reste responsable de la livraison des bénéfices attendus. Il mobilise ses relations internes pour lever les obstacles politiques. Un promoteur qui délègue sa présence au comité de pilotage n’est plus un promoteur.

Le directeur de projet. Il répond de la livraison de la nouvelle solution. Il dirige la planification des travaux et des estimations, veille au respect de la portée, des échéanciers et du budget, met en place les processus de gestion requis et rend compte de l’avancement au promoteur.

Le PCO (contrôleur de projet). Il s’assure que les processus de gestion sont réellement appliqués : suivi des heures, des risques, des changements, des livrables. Il aide le directeur de projet à préparer une reddition de comptes fiable. Sur un projet de plus de 5 000 heures, ce rôle libère le directeur de projet pour ce qui compte : les décisions.

Qui conçoit la solution : l’architecte, l’analyste d’affaires et l’expert en progiciels ?

Trois rôles conçoivent la solution : l’architecte de solution, qui assume le leadership technique et l’intégration ; l’analyste d’affaires, qui maîtrise les besoins et représente les « clients » du projet ; et l’expert en progiciels, qui résout l’adéquation entre les besoins et les fonctionnalités du logiciel. Leur dialogue quotidien évite les personnalisations coûteuses.

L’architecte de solution. Il s’assure qu’aucune composante ne manque (solution d’affaires, ERP, modules spécialisés), conçoit les intégrations avec les systèmes en place, valide les flux de données et révise les structures de données majeures. Il confirme la validité de l’approche d’implantation et guide l’équipe dans sa compréhension de la solution. Le rôle de l’architecte de solutions en 2026 dépasse largement l’expertise technique.

L’analyste d’affaires. Il maîtrise les besoins d’affaires que le projet vise à satisfaire, conçoit les nouveaux processus avec l’expert en progiciels, choisit les meilleures pratiques à incorporer et participe activement aux essais. Il travaille avec les propriétaires de processus jusqu’à l’acceptation de la solution. Nous détaillons le rôle de l’analyste d’affaires dans les projets TI dans un article distinct.

L’expert en progiciels. Il travaille avec les experts d’affaires pour faire correspondre besoins et fonctionnalités, paramètre les applications et appuie la validation de la solution. Il apporte l’expertise produit sans laquelle le projet réinvente ce que le logiciel fait déjà.

Qui construit et déploie : le développeur, le responsable des infrastructures et le responsable de la gestion du changement ?

Trois rôles construisent et déploient : le développeur, qui programme les conversions, les interfaces, les rapports et les adaptations ; le responsable des infrastructures, qui traduit les besoins en serveurs, réseau et logiciels fonctionnels ; et le responsable de la gestion du changement, qui prépare l’organisation à adopter les nouveaux processus. Le troisième est presque toujours le premier qu’on coupe.

Le développeur. Il prépare les programmes d’importation des données dans le nouveau système, bâtit les interfaces avec les applications existantes, programme les rapports manquants et réalise les adaptations nécessaires aux particularités de l’organisation. Chaque adaptation doit être justifiée : les modifications aux progiciels restent une habitude très coûteuse.

Le responsable des infrastructures. Il analyse les besoins pour les traduire en solution d’infrastructure adéquate, installe serveurs, réseau, logiciels et périphériques, et garantit le bon fonctionnement de l’infrastructure tout au long du projet, y compris les environnements de test.

Le responsable de la gestion du changement. Il énonce les stratégies de communication, de formation et de développement organisationnel nécessaires à l’adoption des nouveaux processus. Il accélère la maturation de l’équipe de projet elle-même. Gartner classe la faible adoption par les utilisateurs parmi les principales causes d’échec des ERP ; la gestion du changement est beaucoup plus qu’un plan de communication.

Un rôle sans titulaire, c’est une décision que personne ne prend et une facture que tout le monde paie.

Comment adapter ces rôles à la taille de votre projet ?

Les neuf rôles restent pertinents quelle que soit l’envergure du projet, mais leur intensité varie : une PME de 80 employés confiera souvent plusieurs rôles à une même personne, alors qu’un projet multi-sites exigera un titulaire à temps plein pour chacun. D’autres rôles s’ajoutent selon la nature du projet et la culture de l’organisation : responsable des données, responsable des essais, propriétaires de processus.

La règle ne change pas : chaque rôle a un nom, une personne et un temps réservé, écrits dans la charte de projet avant le lancement.

Questions fréquentes

Quelle est la différence entre le promoteur et le directeur de projet ?

Le promoteur répond des bénéfices d’affaires et fournit les ressources : il siège à la direction, tranche les décisions majeures et lève les obstacles politiques. Le directeur de projet répond de la livraison : portée, échéancier, budget et processus de gestion. Le premier décide pourquoi et avec quels moyens ; le second organise comment et rend compte au premier.

Qu’est-ce qu’un PCO dans une équipe de projet ?

Le PCO (Project Control Officer, ou contrôleur de projet) s’assure que les processus de gestion prévus sont réellement appliqués : suivi des heures, des coûts, des risques, des demandes de changement et des livrables. Il prépare les tableaux de bord et aide le directeur de projet à produire une reddition de comptes fiable pour le comité de pilotage.

Une même personne peut-elle cumuler plusieurs rôles ?

Oui, et c’est courant dans les PME. Un analyste d’affaires peut aussi agir comme expert en progiciels, un directeur TI comme responsable des infrastructures. Deux cumuls sont toutefois risqués : promoteur et directeur de projet, parce que personne ne surveille plus la livraison, et directeur de projet et gestion du changement, parce que l’adoption passe toujours en second.

Pourquoi nommer un responsable de la gestion du changement dès le début ?

Parce que l’adoption se décide pendant le projet, pas après. Gartner cite la faible adoption par les utilisateurs et le manque de compréhension du changement organisationnel parmi les causes d’échec les plus fréquentes des ERP. Un responsable nommé dès le cadrage planifie les communications et la formation au rythme du projet, plutôt que trois semaines avant le démarrage.

Quel rôle représente les utilisateurs dans un projet TI ?

L’analyste d’affaires représente les « clients » du projet. Il maîtrise les besoins, travaille avec les propriétaires de processus et participe aux essais jusqu’à l’acceptation de la solution. Il ne remplace pas les utilisateurs clés eux-mêmes, qui doivent être libérés de leurs tâches courantes pour valider les processus, mais il structure et défend leur voix auprès de l’équipe.