Projets informatiques : éléments importants pour le dialogue social

Avertissement

Cette page présente (ou rappelle) des caractéristiques de la gestion des projets informatiques qui sont importantes dans la perspective de l’introduction du dialogue social dans ces projets.

Il s’agit donc d’une présentation de la gestion des projets de SI informatique (ou numériques) qui ne se veut pas technique, et ne recherche aucune exhaustivité.

La page s’adresse avant tout à des non informaticiens.

Sommaire

Impact de l’application (objet du projet) sur les processus de travail
Les besoins/exigences
Méthodes de conception d’applications : cycles de vie
Acteurs d’un projet numérique, Comités
Les dettes que peut générer un projet informatique : dette technique, dette sociale

Impact de l’application (objet du projet) sur les processus de travail

Un point important pour le dialogue social dans l’approche d’un projet informatique est d’identifier très en amont si la future application s’intègrera dans les processus existants (avec d’éventuelles modifications de processus marginales) ou bien si sa finalité même est de soutenir une réingénierie de process.
Dans ce dernier cas, les processus implantés dans l’application seront les nouveaux processus visés par le management (parfois avec l’accord des utilisateurs), processus auxquels devront se conformer les utilisateurs.

L’impact sur les conditions de travail, le bien-être au travail, ne sera bien entendu pas le même dans les deux cas. Le dialogue social pendant le projet devra en tenir compte.

Les besoins/exigences

Les besoins sont à l’origine et à la base de tout projet de SI numérique.
Les besoins sont portés par le pilote métier du projet, la maîtrise d’ouvrage, les futurs utilisateurs, même si la maîtrise d’œuvre (chef de projet, architectes, développeurs…) peut être amenée à reformuler certains besoins, voire à les rédiger (suite à des entretiens).

La réussite du projet, l’efficacité de l’application, mais aussi le bien-être au travail qui se fera en lien avec ce logiciel, dépendent en grande partie de la complétude et de la précision des besoins exprimés.

Les exigences sont exprimées pendant la première phase du projet (cadrage) et affinés pendant la deuxième (conception).

Nota : dans APIDOR, il n’est pas fait de distinction entre les termes « besoin » et « exigence », qui sont donc utilisés ici indifféremment, comme des synonymes.

Exigences fonctionnelles, exigences non fonctionnelles

Il y a plusieurs façons de classer les besoins (exigences).
Mais une distinction est en général faite entre exigences fonctionnelles et exigences non fonctionnelles.

Exigences fonctionnelles (EF)

Les exigences fonctionnelles expriment ce que l’application doit faire, les services qu’il doit rendre, les fonctions qu’il doit assurer : traitements qu’il doit réaliser (dont les types d’interaction avec des agents humains), calculs, traitement des données, entrées qu’il recevra, leurs formats et leurs sources (documents, interactions avec un agent, entrées en provenance d’autres applications…), sorties qu’il produira, leurs formats et leurs supports (documents imprimés, écrans, données à transférer vers d’autres applications…), données qui doivent être mémorisées.
On s’intéresse ici à l’application vue comme une boîte noire, et non à son fonctionnement technique interne.

Nota : les exigences fonctionnelles détaillées sont souvent écrites par la MOE (et parfois il en est de même pour les exigences fonctionnelles générales), ou par la MOA, mais très rarement par les personnes directement concernées (utilisateurs de la future application). C’est en général le cas pour les « User stories » des démarches agiles (voir Dialogue social dans les Approches agiles).

Exigences non fonctionnelles (ENF)

Il s’agit des qualités ou propriétés attendues de l’application, des conditions (contraintes) dans lesquelles il doit fonctionner. Elles sont essentielles pour la réussite de l’application, mais sont souvent imprécises, difficiles à décrire.

De nombreuses typologies d’exigences non fonctionnelles existent. Elles se centrent en général sur des thématiques essentiellement techniques portant par exemple sur : la sécurité (capacité de repérer et bloquer les intrusions…), la fiabilité (tolérance aux pannes…), la performance (temps de réponse…), le maintien en condition opérationnelle (capacités d’analyse et de confinement des défaillances …), l’évolutivité (capacité d’adaptation aux évolutions de l’environnement technique…), les contraintes réglementaires (normes, règlements nationaux et européens…), l’utilisabilité (facilité d’apprentissage, ergonomie des interfaces…).

La dernière thématique (l’utilisabilité, parfois désignée comme « ergonomie ») est en général peu approfondie : on évoque la facilité d’utilisation, la rapidité de l’apprentissage nécessaire… sans que ces notions ne soient définies en détail. Que signifie par exemple « facile à utiliser » sans précision temporelle ? « Facile à utiliser » après une heure, un jour… de formation ? Après trois mois, un an… d’utilisation ?

La notion d’« expérience utilisateur » (UX)¹ veut dépasser celle d’utilisabilité par la prise en compte d’aspects d’esthétique, d’émotion, de plaisir, etc. dans l’interaction de l’utilisateur avec l’application. Cette notion est souvent utilisée pour des utilisateurs externes, par exemple des clients qui achètent à partir d’une application Web.

Quand elles sont évoquées, les conditions de travail le sont essentiellement sous l’angle des risques d’erreurs par les utilisateurs qu’elles pourraient provoquer. Et non donc sous l’angle de la prévention des risques sur la santé, ni du bien-être et de la citoyenneté au travail (voir la définition d’APIDOR pour cette dernière notion au point « Thématiques du bien-être et citoyenneté au travail« , page La façon de penser).

Notons aussi que des thématiques comme l’éthique sont rarement considérées, et quand elles le sont, ne renvoient en général qu’au respect de certaines normes ou règlements (RGPD par exemple).

Méthodes de conception d’applications : cycles de vie

Il existe de très nombreuses démarches, méthodes, outils de modélisation, outils de génie logiciel… pour la conception des logiciels.

Dans APIDOR le choix a été fait de ne se rapporter à aucune méthode en particulier. Seuls quelques exemples sont parfois donnés, dans un simple but d’illustration, sans aucune recherche d’exhaustivité ni de représentativité.

Les démarches et méthodes de conception sont habituellement classées selon le modèle de cycle de vie du projet qu’elles suivent (processus par lequel on arrive à répondre au besoin, liste des étapes et passage d’une étape à l’autre) : en cascade, en V, en W, en spirale.
Selon le modèle suivi dans le projet, la forme et les moments clés du dialogue social pourront varier.

Cycle de vie du projet vs cycle de vie de l’application

La gestion d’un projet informatique s’arrête au déploiement de l’application (et aux premières actions de maintenance).

Notons que le cycle de vie entier de l’application doit également faire l’objet d’une gestion structurée, impliquant les acteurs concernés (dont les utilisateurs et les personnes impactées par l’application) ou leurs représentants.
Des évolutions seront, en effet, nécessaires tout le long de la vie de l’application selon une logique que Pierre Caye² qualifie de « développement évolutif continu », « caractéristique de toutes les opérations de maintenance ».

Modèle en cascade

Il s’agit d’un cycle essentiellement séquentiel. Dès qu’une phase est considérée terminée (c’est une décision prise sur la base de documents ou de réalisations), on passe à l’étape suivante (flèches noires).

Les retours en arrière (flèche grises en pointillé) sont possibles seulement d’une phase vers celle qui la précède. Cet effet tunnel est le problème essentiel que pose ce cycle : par exemple, une erreur de conception (notamment dans la compréhension d’un besoin) identifiée en phase de déploiement sera très couteuse à corriger car il faudra « remonter » trois étapes de la cascade. Le risque est que les erreurs provenant des phases les plus amont ne soient pas, ou pas totalement, corrigées.

Modèle en V

Le modèle de cycle en V (et sa variante en W) a été développé pour limiter les risques d’identification tardive d’erreur. Ce modèle reste cependant séquentiel (c’est en fait une variante du modèle en cascade), et comporte toujours un risque d’effet tunnel.
L’attention est ici portée tout particulièrement sur les étapes de vérification et validation, qui sont définies en détail.

Modèles en spirale, itératif, itératif et incrémental

Ces modèles représentent une rupture par rapport aux modèles précédents.
Leur principe commun est celui d’une progressivité dans le développement du SI numérique, avec des cycles courts, permettant des livraisons (et des validations) fréquentes tout au long du projet. Le feedback régulier du client permet de s’assurer dès les premières livraisons (très tôt dans le projet) que ce qui est livré est conforme aux attentes.

À l’origine, on trouve la conviction que les besoins ne peuvent pas être tous exprimés en détail en début de projet. Les besoins du client, des futurs utilisateurs, peuvent évoluer en cours de projet (évolution de la stratégie de l’organisation, changements dans son environnement économie ou réglementaire…). Par ailleurs, le fait de pouvoir utiliser très vite de premières versions du logiciel (ou de certains de ses modules), peut engendrer chez le client une meilleure compréhension de ce qu’il peut attendre de l’application, et par suite une évolution de l’expression de ses besoins.

Parmi les méthodes qui suivent ce type de cycle, les plus répandues sont les démarches agiles (voir Dialogue social dans les Approches agiles). Elles sont nombreuses : DSDM³, XP⁴, Scrum⁵…
Les illustrations données dans APIDOR sont issues de Scrum.

Nota : le cycle en spirale peut être utilisé dans une liste plus ou moins extensive des phases d’un projet. L’ensemble du projet peut être géré en agile, ou bien le cycle peut concerner uniquement les étapes à partir du développement (inclus), les deux premières phases (cadrage et conception) étant alors menées en amont en mode séquentiel. Dans ce deuxième cas, on parle de démarche hybride (ou de cycle semi-itératif).

Scrum est une approche itérative et incrémentale, qui fonctionne sur la base de sprints successifs. Un sprint est une itération qui se déroule sur un temps limité (de quelques jours à un mois) et qui produit une livraison ajoutant un nouveau contenu (incrément) à l’application en développement.

Chaque sprint se termine par un retour sur le déroulement du sprint afin d’améliorer les pratiques de l’équipe.

Acteurs d’un projet numérique, Comités

Nota sur la distinction MOA et MOE

Dans la gestion de projet, on distingue classiquement la maîtrise d’ouvrage (MOA) et la maîtrise d’œuvre (MOE).

La maîtrise d’ouvrage (MOA) représente le propriétaire de l’ouvrage (ici le SI numérique développé dans le projet), le versant besoins métier. La MOA fait réaliser l’ouvrage et, en fin de projet, le met en exploitation.

Le maîtrise d’œuvre (MOE) est responsable de la réalisation technique de l’application répondant aux besoins exprimés par la MOA. La MOE est responsable des choix techniques, de la bonne réalisation et de son adéquation avec les besoins exprimés par la MOA (besoins fonctionnels et non fonctionnels).

Acteurs du projet

Nous présentons ici des listes relativement fournies de types d’acteurs. Certains types d’acteurs peuvent cependant être absents de certains projets, notamment dans le cas de petits projets.
Par ailleurs, les acteurs et leurs rôles ne sont pas toujours simples à définir. Il arrive qu’un acteur tienne plusieurs rôles : financeur et commanditaire, commanditaire et client, client et utilisateur, analyste métier et utilisateur-clé, concepteur et développeur…

Tous les rôles d’un projet peuvent être sous-traités, sauf celui de pilote du projet et de financeur.

Les acteurs de la MOA (le côté métier, besoin) : gestion de projet « classique »

• Le pilote du projet (commanditaire, sponsor) : celui qui est à l’origine du lancement du projet.
  Acteur essentiel, il porte la vision stratégique, les enjeux du projet. Il prend les décisions structurelles, d’objectifs, de modification du périmètre du projet, de réallocation du budget… Il doit valider les changements de cap s’il y a des problèmes techniques. Il a un droit de signature sur le projet (car il dispose d’un budget pour le projet).
• Le financeur : il apporte les ressources financières nécessaires à la réalisation du projet. Il peut s’agir du client, du pilote, plus rarement du MOA, ou même parfois de financeurs externes.
• Le MOA (maître d’ouvrage, Product Owner) : c’est en général le client (individu, collectif ou organisation), celui auquel le logiciel qui sera développé est destiné. De moins haut niveau hiérarchique que le pilote, il est là tout au long du projet, contrairement au pilote qui n’est présent qu’à des moments essentiels. Il participe à des réunions hebdomadaires ou plus fréquentes encore. Il doit connaître le métier, c’est un agent du système de production métier (mais il arrive parfois que ce soit un consultant).
• L’assistant MOA (AMOA), analyste fonctionnel : présent tout au long du projet, il doit avoir une connaissance métier et une expérience de projets informatiques. Il recueille les besoins de la MOA, pour alléger le travail de la MOA. Il est responsable de la traduction des besoins en spécifications fonctionnelles destinées à l’équipe de développement. Le plus souvent, il s’agit d’un consultant externe.
• Les analystes métier (business analysts, experts/consultants fonctionnels, technico-fonctionnels) : soit des opérationnels, soit des sachants métier. Acteurs centraux pour l’analyse de l’existant, l’expression des besoins, les validations. Parmi les analystes métier, un chef de projet fonctionnel est parfois désigné, mais souvent ce rôle est confondu avec celui de l’AMOA ou du MOA.
• Des spécialistes sur des sujets particuliers ne relevant pas du métier au sens strict : il existe des règlements, des normes… qui vont produire des exigences qui ne relèvent pas du métier concerné. Le pilote ou le MOA (ou le chef du service dans lequel l’application sera implanté) doivent connaître ces exigences et doivent alors faire appel à des spécialistes (juristes, responsable sécurité…).
• Les utilisateurs : les futurs utilisateurs de l’application (et éventuellement, mais beaucoup plus rarement, des personnes impactées mais non utilisatrices). Parmi les utilisateurs, on distingue en général plusieurs types de rôles :
  • les utilisateurs finaux, qui utiliseront le futur logiciel dans leur travail
  • le MOA peut identifier (ou désigner) des utilisateurs-clés (key users). Ce sont des référents métier qui vont avoir un rôle plus important et plus régulier dans l’expression des besoins et la recette.
  • de même le MOA peut souhaiter disposer d’utilisateurs pilotes qui testeront l’application en avance de phase.
• Les parties prenantes (tiers) : ce sont les personnes, collectifs ou organisations qui ont un intérêt direct ou indirect dans le projet, ou seront impactées par l’application qui sera développée.

Les acteurs de la MOE (le côté technique, réalisation) : gestion de projet « classique »

En cas de développement de l’application (et non d’achat d’un logiciel sur étagère) :

• Le chef de projet technique (le MOE) : il est en charge de l’organisation du travail de l’équipe, du suivi de la réalisation.
• Le PMO : peut être chargé spécifiquement de la planification du projet et de la coordination et de l’exécution. Mais dans beaucoup de projets informatiques, quand un PMO existe, il se concentre essentiellement sur le contrôle des plannings et des coûts.
• L’équipe de développement : concepteurs, développeurs, ingénieurs de différentes spécialités (langages de programmation, systèmes, technologies particulières…).
• L’architecte : il réalise l’analyse technique nécessaire pour établir le plan de construction d’un logiciel, d’un réseau, d’une base de données, etc.
• Le responsable des tests : il conçoit et met en œuvre les plans de tests, construit ou valide les jeux d’essai et exécute les tests pour détecter d’éventuelles anomalies.

En soutien à l’équipe MOE, divers acteurs spécialisés peuvent éventuellement intervenir dans le projet :

• L’administrateur réseau : est chargé de la gestion et de la maintenance de l’infrastructure réseau du projet informatique.
• Le responsable de la sécurité : est responsable de l’élaboration, de la mise en œuvre et de la surveillance des mesures de sécurité nécessaires pour prévenir les intrusions et les violations de données.
• Le spécialiste en infrastructure : est responsable de la conception, de la mise en place et de la maintenance de l’infrastructure matérielle nécessaire au projet informatique.
• Le responsable de la documentation : chargé de la constitution et de la gestion de la documentation liée au projet et à l’application développée (documentation technique, manuels d’utilisation…).
• Une équipe de Design Thinking
  Composée en partie d’ergonomes, l’équipe va s’intéresser à l’« expérience utilisateur1 » (UX), aux interactions entre les différents utilisateurs…

Notons que dans certaines organisations, certains projets construisent des applications qui peuvent être utilisés par des utilisateurs internes (professionnels) aussi bien qu’externes (client externe, utilisateur final). La logique est souvent que l’application soit développée dans le but que des fonctions réalisées en interne puissent dans un avenir plus ou moins proche être faites uniquement en externe, par les clients ou usagers eux-mêmes. L’« expérience utilisateur » est alors très proche de (sinon totalement assimilée à) l’« expérience client ».

Cas de l’achat d’un logiciel sur étagère

En cas d’achat de progiciel, des acteurs externes collaboreront avec des acteurs internes.
Les premiers seront essentiellement la société éditrice du logiciel sur étagère choisi, et en général aussi une ESN intégratrice spécialisée dans ce progiciel : commerciaux, des consultants métier, consultants techniques.

Parmi les acteurs internes, ceux relevant de la MOA (le côté métier, besoins) auront un rôle à jouer, surtout dans le cas d’un progiciel complexe nécessitant d’importants paramétrages (par exemple un ERP). Dans le cas de progiciels relativement simples (et ne demandant pas de paramétrage complexe), l’équipe informatique peut être très réduite et faiblement impliquée, sauf dans les étapes de recette, de déploiement et de maintenance. Mais s’il s’agit d’un progiciel complexe, une équipe informatique devra coopérer étroitement avec l’ESN intégratrice et parfois aussi avec la société éditrice.

Acteurs : spécificités des démarches agiles (exemples issus de Scrum)

L’organisation des équipes et des rôles dans les démarches agiles (ici Scrum) suit une logique spécifique, qui diffère de celle des projets non agiles.
Les rôles sont moins nombreux, et chacun correspond souvent à la fusion de différents rôles des projets non agiles. Les équipes sont en général plus polyvalentes que dans les projets menés en séquentiel (cascade, V ou W).

Les rôles spécifiques sont les suivants.

• Le Product Owner (PO) : il représente l’essentiel de la MOA (le côté métier, besoins). Il valide toutes les décisions autour du produit et du contenu du carnet de produit. Son rôle peut parfois être aussi celui de pilote du projet, avec la latitude de prendre des décisions stratégiques dans le projet.
• Le Scrum manager (SM) : il correspond approximativement au chef de projet MOE, mais ce rôle peut être également parfois tenu par le PO. Le SM est responsable de la méthodologie employée, il accompagne les équipes dans l’utilisation des composantes de Scrum (événements, artefacts, etc.).
• L’équipe de développement : rôle de réalisation de la solution technique. Les membres de l’équipe sont responsables de l’incrément, du carnet de sprint et donc de la manière dont sera réalisée l’application. Ils peuvent être également en charge de l’estimation de la charge et du temps de réalisation de chaque item.

Le PO, le SM et l’équipe de développement constituent l’équipe Core (noyau) de Scrum. Celle-ci intervient sur le projet conjointement aux autres parties prenantes : le Commanditaire (client) qui est l’initiateur du projet, le Financeur (quand il est distinct du Commanditaire) qui apporte le support financier au projet, les utilisateurs à qui l’application est destiné. Ces derniers ont un rôle essentiel pour les validations et l’orientation des décisions qui seront prises quant aux fonctionnalités de l’application.

Comités

Un certain nombre de comités participent en général à la gouvernance d’un projet informatique.

Nous présentons ici les principaux comités.

Comité stratégiques (COSTRA, sponsor committee)

Il décide des changements de stratégie. Si le projet doit évoluer, il prend des décisions pour réduire le risque.
Il est réuni surtout au début du projet (phase cadrage) et en toute fin, et lorsque des décisions stratégiques sont requises.

Comité de pilotage (COPIL, steering committee)

C’est l’instance décisionnaire (excepté pour les changements de stratégie, qui relèvent du COSTRA). Il est constitué majoritairement des acteurs métier, et comprend le commanditaire ou son représentant, le MOA, l’assistance MOA ou le chef de projet fonctionnel, les acteurs métier des domaines principaux (+ éventuellement des domaines annexes), le chef de projet MOE.

Il contrôle l’avancement du projet par rapport au planning initial, les coûts réels par rapport au budget initial, l’évolution éventuelle des risques…

Il prend les décisions sur le mode de réalisation (achat logiciel sur étagère ou développement), sur l’avancement du projet (valide le passage d’une étape à une autre), valide les livraisons, fait les arbitrages de planification et de répartition des ressources.

Il liste les points demandant des décisions au niveau du COSTRA.

Périodicité : pendant les phases amont, le COPIL peut être réuni une fois par semaine ou par 15 jours. Ensuite, les réunions sont beaucoup plus espacées, sauf questions urgentes.

Comité de projet (COPRO, comité de suivi)

Traite des questions opérationnelles (du suivi opérationnel) au sens large.
Il comprend le MOA et/ou l’assistance à MOA, le chef de projet technique, éventuellement des membres de l’équipe de la MOE et des utilisateurs-clés.

Il suit l’avancement du projet au niveau opérationnel, et se centre principalement sur le périmètre du projet et ses livrables. Pour l’équipe de la MOE, il peut être un lieu d’échanges sur les difficultés rencontrées et favoriser un partage d’expérience.

Il liste les points demandant des décisions au niveau du COPIL.

Périodicité : hebdomadaire, voire plus fréquent dans des moments particuliers.

Comité d’utilisateurs

Cette instance est loin d’être présente dans tous les projets.

Sa composition est en général décidée par le MOA et par le directeur du service dans lequel sera implanté le logiciel. Seront désignés des utilisateurs avec de fortes compétences métier. Il n’est pas vraiment recherché que la composition du comité reflète la diversité des futurs utilisateurs.

Il comprend des utilisateurs-clés, qui seront impliqués dans certaines phases du projet (notamment l’analyse de l’existant et des besoins, recette). Dans le cas de démarches agile, ils peuvent être sollicités pendant le développement.

Le rôle du comité d’utilisateurs est aussi de promouvoir le projet, puis l’application, dans le service destinataire.

Les dettes que peut générer un projet informatique

Dette technique

« La dette technique est un concept utilisé en informatique pour décrire le coût à long terme de solutions rapides ou temporaires adoptées lors du développement logiciel. Cela se produit lorsque les développeurs choisissent des solutions qui permettent de répondre rapidement à un besoin immédiat, mais qui peuvent entraîner des problèmes ou des coûts plus importants à long terme. »⁶

Remarque : les « problèmes » évoqués dans cette définition peuvent altérer fortement la qualité de la vie au travail, et demander des efforts parfois très fortement accrus aux utilisateurs du logiciel concerné pour garder le niveau d’efficacité demandé par le management.
Notons qu’une dette technique peut apparaître aussi dans le cas de l’achat d’un logiciel sur étagère choisi parce que moins coûteux, mais qui s’avèrerait mal adapté, et devrait par la suite être changé (mais non sans que le logiciel ait généré des problèmes de tous ordres dans les conditions de vie au travail).

Dette sociale

Les impacts d’une application informatique sur le bien-être des salariés de l’organisation doivent être pleinement pris en compte lors du projet.

Ignorer ces impacts, ne pas considérer le dialogue social comme un facteur de succès du projet informatique (au prétexte de l’efficacité et de la rapidité), conduira très probablement à constituer ce que nous désignons comme une « dette sociale ».

Par « dette sociale » nous entendons une dégradation du bien-être au travail (santé incluse), une perte de citoyenneté au travail (totale ou partielle) générées par l’usage du nouveau logiciel.
L’hypothèse d’APIDOR est que l’existence d’un dette sociale importante, comme celle d’une dette technique significative, sont de nature à dégrader la performance de l’organisation.