Partage de responsabilité entre l’architecte et le chef de projet

Une distribution claire du périmètre entre le chef de projet et l’architecte est indispensable pour assurer le succès du projet et mérite de ne pas se satisfaire de l’implicite.
L’architecte est en charge à minima de définir l’architecture du système, c’est-à-dire de réaliser l’architecture boîte noire et boîte blanche de son système, de modéliser le système et les chaînes de valeur dans l’architecture, de proposer, justifier et choisir des architectures concurrentes, d’évaluer les architectures en maturité et en conformité aux besoins prioritaires, de gérer les interfaces, de conduire des analyses d’impacts, de valider et vérifier le système.

Le chef de projet quant à lui, à minima, pilote les coûts, risques et délais du projet.
En matière d’atteinte des objectifs Qualité, Performance, Coût et Délai du projet, l’architecte est responsable (« Accountable » au sens du RACI) des objectifs Qualité et Performance qui lui sont alloués (en prenant en compte les contraintes Coût et Délai), tandis que le chef de projet est responsable (« Accountable » au sens du RACI) des objectifs Coût et Délai qui lui sont alloués (en prenant en compte les contraintes Qualité et Performance).

En cas d’impossibilité d’atteindre les objectifs Qualité et Performance avec les contraintes Coûts et Délai, se pose alors la question de savoir qui arbitre. Le chef de projet étant responsable (possiblement en délégation) du QCDP global du projet, c’est soit lui qui possède ce pouvoir d’arbitrage, soit une autorité supérieure.
Dans tous les cas il est important de bien identifier cette autorité dès le lancement du projet.

Nota:
Nous parlons ici bien de rôle et pas d’acteur. Il faut garder en tête qu’il peut y avoir des cas où :

• La personne qui porte le rôle d’architecte porte aussi les objectifs Coût et Délai (sur un sous périmètre par exemple). Cet acteur joue alors également un rôle de chef de projet sur ce sous-périmètre.
• La personne qui porte le rôle du chef de projet porte aussi les aspects Qualité et Performance (sur une phase spécifique du projet ou sur un projet de reconduction ou dit « business as usual»). Cet acteur joue alors également un rôle d’architecte.

Parmi les principaux écueils, on notera :

• Les rôles non clairement explicités : qui est responsable de quelle activité et de quel objectif ? Par qui et comment sont fait les arbitrages?
• La problématique de bande passante, c’est-à-dire de charge des acteurs qui ne peuvent pas réaliser l’ensemble des activités et responsabilités qui leur incombent ;
• La non-explicitation des résultats d’arbitrages ;
• La prise de décisions qui vont au-delà du périmètre de délégation du projet (ex : dégradation de la qualité du produit qui a un impact sur l’image de l’entreprise et/ou son business) ;
• Les confusions entre rôle et titre qui peuvent générer des ambiguïtés (ex : un architecte qui aurait un rôle de développeur sur un projet) ;
• Des chefs de projet portant historiquement la responsabilité technique des projets ce qui peut complexifier la mise en place d’un nouveau rôle d’architecte. Souvent les chefs de projets système (même programme parfois) font des choix d’architecture sans en avoir conscience ce qui induit des risques/couts non étudiés et anticipés (par exemple : choix de sous-traitants sur des aspects financiers uniquement, sans prendre en compte des évaluations techniques).

Sans exclusif, voici quelques bonnes pratiques à prendre en compte :

• Les rôles doivent être explicités au début du projet ainsi qu’à tout changement d’organisation ;
• Les arbitrages doivent être explicités sur les différentes phases projet (cela peut être juste un compte rendu ou de façon plus détaillée, un dossier de justification des choix) ;
• Il convient d’adapter l’organisation (quelle somme de responsabilité doit porter l’architecte) en fonction de la complexité du composant/sous-système ainsi que la complexité du reporting (KPI & modèles). Souvent le contexte sectoriel ou organisationnel conditionne le choix du partage de responsabilité entre l’architecte et le chef de projet ;
• En plus de la clarification des rôles, il est recommandé de mettre en place une formation sur le métier d’architecte pour les acteurs projet.

Nous avons compilé ici un certain nombre de verbatims de chef de projet ou d’architecte système de différentes entreprises, et qui font écho à cette distinction nécessaire des rôles :

“Pour assurer un rôle d’architecte tout au long de la vie du projet nous avons nommé un responsable d’intégration et test qui prend de facto le rôle d’architecte après la phase d’étude du projet ;

“ Dans le cadre de gros projets, nous avons des responsables de lot qui sont des chefs de projet et des architectes qui ont délégations des objectifs QCDP sur leur périmètre et sont pilotés par le nœud du dessus ;

“Sur un petit projet, nous avons un responsable technique qui joue un rôle d’architecte ;

“ Nous optons pour une répartition des rôles en fonction des projets et du profil des ressources disponibles au moment du lancement du projet, avec 3 rôles clefs identifiés et incarnés :
• Le chef de projet système (en charge de la gestion du coût, du délai, du planning)
• L’architecte système (en charge de la conception, définition de la solution et choix techniques répondant au besoin du client)
• Un responsable IVVQ (concentré sur la partie aval du cycle en V). Il s’assure que ce qui est livré est en phase avec ce qui a été spécifié

“ Dans les petits projets, le chef de projet peut avoir également le rôle d’architecte : il s’occupe des spécifications avec un ingénieur système, qui est alors le responsable technique. Dans de plus gros projets, un rôle de responsable technique vis-à-vis du client peut également être défini : il s’agit alors d’un architecte impliqué dans la remontée du cycle en V.

“Nous avons une organisation où les rôles sont beaucoup plus compartimentés avec :
• Un chef de programme qui porte le QCDP du programme
• Un project design authority, responsable technique sur le projet vis à vis du client
• Un architecte système, responsable technique en interne lors des phases de conception
• Un responsable ingénierie système, responsable de conduire les activités d’ingénierie système sur le projet
• Un responsable intégration vérification et validation en charge des activités d’intégration et de V&V

“ Nous avons une organisation où la taille et le délai important des projets nécessitent un partage de responsabilité technique entre des responsables techniques et un architecte. Les responsables techniques sont chargés de lots (correspondant à des lots d’études métier sur un périmètre produit). Le responsable de lot a la charge de la réalisation des études techniques sur son lot (ex : notes de dimensionnement mécanique) et réalise le suivi budgétaire de ses activités. Ce sont des appuis pour l’architecte. L’architecte, lui, porte la responsabilité de la performance du produit, et contrairement au responsable technique, il n’a pas d’aspect budgétaire à gérer. A noter que cette répartition a été pensée pour pallier des problématiques historiques où les responsabilités solution, budget et planning étaient portées par un même rôle sans que cela ne soit tenable : il y avait soit un traitement des problématiques techniques au détriment des aspects coût et délai, soit au contraire un focus coût et délai au détriment de la technique. La mise en place d’une responsabilité séparée sur la performance du produit a permis de mettre en place un équilibre plus sain entre ces différents aspects à prendre en compte sur les projets et un renforcement de la préoccupation de la conformité du produit final.