Les acteurs d'un projet informatique

Des projets simples aux complexes

À la base, pour un petit projet, nous avons besoin minimalement de deux acteurs : un client et un informaticien. Le client énonce un besoin, il a des objectifs et veut que son travail (ou celui de ses employés) soit plus efficace. Il voit un retour sur l'investissement, en payant les services de l'informaticien qui lui automatisera une partie de ses processus, il voit un gain sur son service à la clientèle, sur ses coûts de production ou autre.

L'informaticien, dans ce genre de projet, fait tout de A à Z. Il prend les besoins, conçoit une solution en collaboration avec le client. Il évalue les coûts et estime le temps que le développement lui prendra. Il programme l'application ou le système désiré. Il fait des essais unitaires, fonctionnels et systèmes. Il installe le système et ses mises à jour, fait la formation et supporte les utilisateurs.

Ensuite, le projet prend de l'ampleur, l'informaticien seul ne suffit plus. Il a le temps que pour prendre les besoins et concevoir des solutions. Il se spécialise alors (s'il a de l'intérêt) en analyste fonctionnel. Puisqu'il n'a pas le temps de réaliser le système, un second informaticien vient l'aider pour programmer, il s'agit d'un programmeur. L'analyste fonctionnel fourni au programmeur des dossiers fonctionnels qui contiennent toutes les spécifications sur le système attendu. Le programmeur écrit le code du système, fait les compilations et installations.

Du côté du client, lui non plus ne suffit plus. Il nomme deux personnes. L'analyste d'affaires est spécialement dédié pour consigner le besoin des utilisateurs, et la vision de la direction de l'entreprise. Il priorise les besoins et évalue les impacts sur l'entreprise. Le pilote de système est en quelque sorte un super utilisateur. C'est lui qui fait les configurations avancées dans le système, c'est aussi lui la personne de référence pour les utilisateurs lorsqu'ils ont des problèmes ou questions avec le système. Cette personne est aussi responsable de faire des essais utilisateurs avant les mises en production du système.

Un chargé de projet s'ajoute aussi à l'équipe. Son rôle est d'encadrer l'équipe de développement afin de s'assurer de respecter les échéanciers et les budgets. Généralement, il assure une direction forte en début de projet pour bien aiguiller son équipe. Par la suite, c'est l'équipe de développement elle-même qui prendra davantage la direction lorsqu'elle maitrisera bien le projet. Le chargé de projet a un rôle de facilitateur. Il aide les personnes à communiquer entre elles et contribue à trouver des solutions lorsqu'il y a des valeurs qui entrent en conflit. Il s'assure constamment que le développement avance bien.

Dans une plus grosse équipe, il y a plus de gens. Qui dit plus de gens, dit nécessairement structure hiérarchique. Non pas nécessairement dans le sens d'autorité, mais davantage dans le sens d'efficacité. Arrivent alors les architectes : l'architecte d'affaires, l'architecte fonctionnel et l'architecte organique. Ils travaillent sur les besoins et les solutions à haut niveau, laissant le détail aux autres intervenants. Ils s'assurent de la cohérence de tout ce qui est fait. Ils aident pour l'évaluation des temps. Ils recensent et pèsent les impacts avant qu'un ajout ou une modification d'une fonctionnalité soit fait au système selon leur secteur (affaires, fonctionnel ou organique). Ils prennent ensemble les grandes décisions quant aux orientations à appliquer. Ils répondent aux questions des membres de leur équipe, encadrent les nouveaux venus, diffusent les informations des décisions prises dans les comités et sollicitent de l'aide aux gens de leur équipe pour faire des prototypes et des simulations.

Parallèlement à l'équipe de développement (incluant ceux qui fournissent le besoin), il y a une équipe dite technologique. Celle-ci travaille à répondre aux besoins matériels et configurations logicielles. Ils déterminent les machines (ordinateurs) à mettre en place pour faire exécuter le système, effectuent les tests de charges, définissent les plans de relève et de sauvegarde et sont présents pour faire les mises en production.

À tout ce monde, s'ajoutent d'autres personnes qui ont des spécialités diverses :

• L'administrateur de base de données (DBA) travaille à ce que la base de données soit cohérente et performante;
• Un ergonome s'assure que les interfaces utilisateurs sont présentées de manière constante, claire, et efficace aux l'utilisateur. Ce dernier fait des tests d'utilisabilité;
• Un graphiste définit les couleurs et produit les images utilisées pour présenter le système;
• L'intégrateur veille à ce que l'arrimage entre les composantes logicielles et/ou systémiques fonctionne bien;
• Les experts en méthodologie aident les équipes à mieux organiser leur travail;
• Les préposés au support aux utilisateurs sont les premiers répondants lorsque les utilisateurs ont des difficultés avec l'utilisation du système;
• Les testeurs (ou responsables en contrôle qualité) conçoivent et réalisent des plans d'essais et s'assurent de la non-régression du système pendant son évolution;
• Etc.

Organisation d'entreprise vs organisation de travail

Généralement, dans les grandes entreprises, ministères ou organismes, tout ce qui touche l'informatique (ou technologie de l'information) fait partie d'une même division administrative. Puis, tout ce qui touche utilisateur, pilotage et ligne d'affaires fait partie d'une autre division administrative. Ces divisions « verticales » ont du sens en termes d'administration et de gestion d'entreprise pour l'organisation des ressources, du budget, etc.

Or, dans le cadre d'un projet, la division se fait davantage de manière « transversale » où les différents individus, de différentes divisions administratives, doivent coopérer et communiquer pour mettre à bien le projet.

Le défi se trouve exactement là. Les politiques et les façons de faire propres à chaque unité administrative dictent les rôles et responsabilités de chacun au sein de leur division, et non pas leur rôle et responsabilités au sein du projet. Lorsqu'une direction forte n'est pas assurée entre les divisions, cela donne lieu à des frictions internes. Un exemple simple pourrait être que l'équipe TI reproche aux utilisateurs de ne pas énoncer leurs besoins clairement, et de l'autre, les utilisateurs pourraient reprocher à l'équipe TI de ne pas fournir assez d'information sur ce qui est possible ou non de faire, afin de pouvoir les éclairer à prioriser et définir leur besoin.

Consultants et internes

Tous les membres de l'équipe travaillent en finalité pour le client. Ils sont soit employés de celui-ci (interne) ou fournisseur de service pour celui-ci (consultant). Ce statut, consultant ou interne, n'a pas d'impact dans le travail de tous les jours au sein d'une équipe. Mais il faut voir tout de même certaines distinctions :

Long terme : les employés (internes) sont engagés pour du long terme. Ils développent l'expertise au sein de l'entreprise et sont en quelque sorte les gardiens du patrimoine applicatif. Ils maîtrisent mieux que qui conque les systèmes en place.

Le court terme : À l'inverse, pour du court terme ou avoir une expertise spécialisée, les consultants sont l'idéal. Leur expérience n'est pas dans l'entreprise, mais une somme d'expérience dans diverses entreprises qui permet d'amener un regard nouveau aux employés internes.