Dialogue social : aspects communs à tout le projet informatique

Contenu

Cette page contient un ensemble de conseils APIDOR qui concernent la totalité du projet, ou sont transversaux à plusieurs phases du projet.

Y sont abordés la place du dialogue social dans le projet informatique, les acteurs et instances (comités) du projet, les points importants pour mener le dialogue social pendant le projet, la question des catégories utilisées pendant le projet (utilisateurs, ENF…), le système de pilotage du projet et le temps du projet ainsi que l’apprentissage organisationnel.

Un tableau des catégories d’exigences (besoins) en matière de bien-être et citoyenneté au travail ainsi que des propositions concrètes de besoin, peut être téléchargé ici.

Sommaire

Place du dialogue social dans le projet informatique
Acteurs et instances (comités)
Quelques points importants pour mener le dialogue social
Catégories utilisées pendant le projet (utilisateurs, ENF…)
Système de pilotage du projet
Le temps du projet, l’apprentissage organisationnel

Place du dialogue social dans le projet informatique

Implication du haut management

Le haut management a un rôle essentiel à jouer dans l’introduction et la promotion du dialogue social dans le projet.

L’introduction du dialogue social dans les projets informatiques doit faire partie des objectifs de haut niveau de l’organisation, voire de sa stratégie.

Un objectif central du projet doit être que l’application développée ne génère pas de « dette sociale » (voir Dettes que peut générer un projet informatique dans la page Projet informatique : points clés).

Ceci suppose que certains dogmes soient combattus, parmi lesquels :

• l’équivalence faite entre rapidité et efficacité
  • qui peut trouver une expression dans l’idée sur le dialogue social ferait perdre du temps dans un projet informatique
  • et qui sera renforcée par des indicateurs de suivi de projet centrés exclusivement sur les coûts (généralement considérés à trop court terme), et sur le suivi du planning.
• le dogme de la complexité signifiant s’en remettre à la parole des experts¹, générant ainsi le risque de voir le dialogue préempté par les experts
• le caractère considéré « naturel » des catégories ou des indicateurs, qui les ferait ainsi échapper au dialogue…

Information en début de projet sur le dialogue social

En début de projet, tous les acteurs impliqués doivent être informés :

• de la décision d’introduire le dialogue social dans le déroulement du projet,
  • afin que soient prises en compte les thématiques du bien-être et de la citoyenneté au travail dans le logiciel qui sera développé
• des objectifs poursuivis par le dialogue social au sein du projet
  • et de la mesure de leur atteinte
• des modalités pratiques du dialogue social dans le projet autour de ces thématiques.

Autant que faire se peut, un consensus ou au moins un consentement² de tous les acteurs doit être recherché.

Acteurs et instances (comités)

Tous les acteurs et instances du projet ont vocation à participer au dialogue social autour du bien-être et de la citoyenneté au travail.
Mais certains acteurs auront un rôle plus essentiel et aussi plus centré sur ces thématiques.

MOA et assistants MOA spécialisés

On peut imaginer en particulier que le MOA porte non seulement les aspects « métier » au sens fonctionnel, mais qu’il soit aussi en charge des aspects de bien-être et de citoyenneté au travail, qui correspondent pour l’essentiel aux conditions concrètes, réelles dans lesquelles les opérateurs [terme proposé par Gabriel] réalisent les tâches métier et au sens que ces tâches revêtent pour eux.

De même, il serait certainement utile qu’il existe dans l’organisation un ou des assistants MOA spécialisés dans la tenue d’un dialogue social sur les thématiques de bien-être et de citoyenneté au travail.

Acteurs métier porteurs des demandes en matière de bien-être et de citoyenneté au travail

Certains acteurs « métier », futurs utilisateurs de l’application, pourront se révéler plus aptes à porter les besoins de leurs collègues sur ces thématiques, et pourront être chargés de les représenter.

Ces acteurs « représentants des utilisateurs » doivent être reconnus comme des membres à part entière, des parties constituantes du projet, et notamment être destinataires des informations partagées dans le projet.

Ils seront un appui à la MOA sur les questions de bien-être et de citoyenneté au travail.
Ils pourront faire partie de certains comités : comité de projet, comité utilisateurs, et de l’instance spécifique si elle est créée.

Représentation du CSE

Dès lors que le projet informatique pourrait avoir des incidences sur les finalités de l’entreprise, sa stratégie ou, plus banalement, dépasserait un certain coût estimé, un représentant du comité social et économique de l’entreprise peut être intégré au projet, dans son ensemble ou pendant certaines phases essentielles (Cadrage par exemple).

Instance spécifique ?

Une instance spécifique peut être envisagée pour la formalisation, la validation et la vérification de la prise en compte des besoins exprimés en termes de bien-être et de citoyenneté au travail.

Une telle instance devrait être composée principalement de futurs utilisateurs de l’application et de personnes qui seront impactées par lui, des « représentants des utilisateurs » ainsi que de l’assistant MOA spécialisé (voir plus haut).

Formation des acteurs

Rappelons que la citoyenneté au travail en général et pendant le projet informatique implique des droits, mais aussi des devoirs. Parmi ceux-ci, le devoir de s’informer est essentiel, mais suppose que l’on ait les compétences pour comprendre l’information disponible. Ces compétences peuvent s’acquérir par l’expérience mais aussi par la formation.

Le dialogue social dans les projets informatiques étant peu ou pas pratiqué dans de nombreuses organisations, des formations spécifiques doivent être envisagées : pour les non-informaticiens sur la gestion d’un projet informatique et ses contraintes, pour tous sur les modalités du dialogue social et sur les thématiques de bien-être et de citoyenneté au travail.

Ces formations pourront être proposées à des assistants MOA qui se spécialiseront dans les thématiques de bien-être et de citoyenneté au travail, à des utilisateurs clés, mais aussi à des chefs de projets informatiques, des Scrum managers, ou encore des personnes susceptibles d’endosser le rôle de MOA.

Quelques points importants pour mener le dialogue social

Nous ne présentons ici que quelques éléments résumés sur les procédures qui doivent permettre le dialogue social.

La méthode ISIDOR fournit un ensemble d’outils, et en particulier des listes de points à vérifier. Nous renvoyons à leur consultation (voir ci-contre).

Pour que le dialogue social puisse se développer pendant le projet, il est important qu’un accord existe entre toutes les parties sur les règles qui permettent d’exprimer des désaccords. C’est la notion de « consensus conflictuel » promue par Ricœur³.

Voici quelques points importants à considérer :

• Instances du projet : complétude de la liste des comités, effectivité de leur rôle, représentativité de leurs membres (telle qu’évaluée par les futurs utilisateurs de l’application et les personnes impactées), procédures de gestion des dissensus et conflits
• Qualité de l’information sur le/en cours de projet : choix de l’information transmise (choix fait par qui ?), destinataires (liste définie par qui ?), possibilités de retour/validation et de demandes de compléments
• Sujets de débats/Ordres du jour des réunions : caractère ouvert de la définition des sujets et ordres du jour, formalisation et transmission des ordres du jour
• Déroulement des réunions : possibilité effective d’expression de tous les participants, caractère explicite et débattu des processus de délibération et de décision, mode de recherche de consensus/consentement
• Acteurs citoyens et non citoyens du projet informatique : répartition des pouvoirs de définition des procédures, des processus de décision, de définition des ordres jour des réunions, de participation effective aux réunions ; pouvoirs des acteurs externes à l’organisation.

Catégories utilisées pendant le projet (utilisateurs, ENF…)

Des catégories, typologies, nomenclatures, classifications… sont présentes à toutes les phases d’un projet informatiques.

Elles peuvent être utilisées pour définir les types d’utilisateurs (pour l’expression des besoins ou pour la définition des droits : voir Modèles de user stories et phase Conception), mais aussi les types d’exigences (besoins) non fonctionnelles (voir Besoins/exigences et Exigences non fonctionnelles dans les approches agiles), les types de critères pour le choix d’un logiciel sur étagère, les types de critères d’acceptation d’une user story, etc.

Aucune catégorie n’est naturelle, les catégories sont toujours construites et elles traduisent toujours une façon de voir les choses, voire une vision du monde, particulière.

Une fois construites, les catégories s’avèrent souvent performatives, au sens où, par le biais des mises en œuvre de décisions et d’outils basés sur ces catégories, elles vont les faire exister réellement (même si à l’origine elles ne correspondaient pas à une matérialité avérée). Mais aussi au sens où elles vont invisibiliser tout ce qui n’appartient pas à la liste de ces catégories.

Le dialogue social doit absolument interroger les catégories utilisées pendant le projet et vérifier qu’elles n’entravent pas la prise en compte effective des besoins liés au bien-être et à la citoyenneté au travail.

Au-delà même, et du fait qu’elles expriment des visions des choses particulières, on peut affirmer que les catégories ne devraient pas être préconstruites, mais au contraire que leur construction même devrait faire l’objet d’un dialogue/d’un débat/d’une négociation.

Deux typologies sont particulièrement à considérer pendant un projet informatique : celle concernant les utilisateurs, celle portant sur les exigences non fonctionnelles (voir plus bas).

Catégories d’utilisateurs

Les catégories d’utilisateurs considèrent en général les utilisateurs uniquement comme des individus, conduisant à l’absence de prise en compte des collectifs de travail dans les projets informatiques. De plus ces typologies sont basées sur des catégories exclusivement fonctionnelles, ne tenant pas compte des conditions de réalisation effective du travail.

Les personae, utilisateurs fictifs constituent une expression de la vision des utilisateurs que peuvent avoir certains acteurs du projet. Les personae peuvent également être performatives.

Catégories d’exigences non fonctionnelles (ENF)

Les typologies, nombreuses, d’ENF ne font en général pas de place aux aspects de bien-être et de citoyenneté au travail. La seule catégorie s’en rapprochant étant celle d’utilisabilité, très limitée (voir ENF).

Il convient de compléter ces typologies avec des ENF portant sur le bien-être et la citoyenneté au travail.

Le tableau suivant présente quelques exemples (non exhaustifs) pour des besoins (exigences) en matière de bien-être et de citoyenneté au travail.

Attention : certains besoins proposés dans ce tableau sont relativement aisés à faire reconnaître, quand d’autres demandent une maturité certaine de l’organisation dans le dialogue social autour du numérique (voir fin de page Vue d’ensemble).​

Certains de ces besoins sont des ENF, d’autres des EF.

Mais les 5 catégories proposées (Exigence d’explicitation & visions alternatives, Autonomie, Décision & système de pilotage, Participation citoyenne à l’évolution du logiciel, Temps & Apprentissage organisationnel) peuvent constituer une typologie d’ENF pour les besoins en bien-être et citoyenneté au travail.

Propositions d’exigences pour le bien-être et la citoyenneté au travail

Système de pilotage du projet

Le système de pilotage du projet doit être connu de tous, ses éléments explicités : objectifs du projet, mode de mesure de leur atteinte, indicateurs retenus et leurs plages de valeurs « acceptable », etc.

Tableaux de bord du projet, indicateurs

Comme on l’a évoqué pour les catégories, aucun indicateur n’est « naturel », tous sont l’expression d’une manière de voir, parfois d’une représentation du monde.

Le dialogue social doit être attentif aux indicateurs choisis, à leur mode de calcul, au choix de leur valeurs… : indicateurs de fin de tâche, de réponse à un besoin (critères d’acceptation) d’efficacité, de qualité, de coûts, de tenue des délais, etc.
Dans un contexte de véritable dialogue social, ces indicateurs doivent être coconstruits et/ou a minima faire l’objet d’un consentement.

Une attention devra être portée aux équilibres dans les tableaux de bord : indicateurs quantitatifs vs qualitatifs, indicateurs financiers vs non financiers, indicateurs a posteriori (mesurant la performance passée) vs a priori (mesurant les déterminants de la performance future).

Les tableaux de bord rassemblant les indicateurs de pilotage du projet doivent être accessibles à tous les acteurs du projet, et notamment ceux dont le travail est évalué par ces tableaux de bord (équipe projet). La définition et le mode de calcul de tous les composants de ces tableaux de bord doit être aisément accessible aux acteurs du projet.

Les personnes plus directement impliquées dans le dialogue social devront pouvoir, en cours de projet, proposer l’ajout d’indicateurs leur semblant utiles.

Deuxième boucle de suivi : il est également souhaitable qu’une revue des tableaux de bord soit effectuée en cours ou au moins en fin de projet pour évaluer la pertinence des objectifs et des indicateurs eux-mêmes.

Le carnet du dialogue social : un outil de suivi

Un document de suivi de tout ce qui concerne le dialogue social et les thématiques qu’il porte peut être très utile.

Ce « carnet de dialogue social » (backlog de dialogue social) doit permettre le suivi de la prise en compte (mais aussi de l’évolution) des besoins issus du dialogue social, les difficultés rencontrées, les arbitrages faits, etc.

Il doit être initialisé en phase de Cadrage avec les besoins exprimés en matière de bien-être et de citoyenneté au travail, et tenu à jour pendant tout le projet.

Il permet de vérifier que l’application inclut bien les besoins liés à ces thématiques, et sert de mémoire au déroulement du dialogue social dans le projet. À ce dernier titre, il peut être un support à l’apprentissage organisationnel du dialogue social dans les projets numériques.

Le temps du projet, l’apprentissage organisationnel

Le temps est une ressource essentielle pour le projet informatique, mais aussi pour le dialogue social.

Le temps total octroyé au projet, mais aussi le planning du projet, devront ainsi être confrontés aux contraintes propres à l’exercice du dialogue social.

Le recueil et la compréhension des besoins liés au bien-être et à la citoyenneté au travail demandent du temps (entretiens…). À ce titre, le planning doit prévoir une remps suffisant pour les deux premières phases du projet, et tout particulièrement la première (Cadrage).

Le dialogue social dans les projets menés selon un approche agile « complète » (qui inclut toutes les phases) pourra être rendu plus difficile par l’absence de ces premières phases dans toute leur extension et demandera une attention particulière (voir Modèle itératif et incrémental et Sprint 0).

Comme cela a déjà été évoqué, dans de nombreuses organisations, le dialogue social dans les projets informatiques n’est que peu ou pas pratiqué. Il y a donc un déficit de connaissances et d’expérience sur ce sujet, aussi bien chez les acteurs de la MOE que chez les acteurs « traditionnels » du dialogue social (représentants du personnel élus…).

La gestion des retours d’expérience, la capitalisation des connaissances sont des enjeux importants pour un apprentissage de l’organisation en matière de dialogue social dans les projets informatiques. Comme on l’a dit, le « carnet de dialogue social » peut être un support à cet apprentissage.

Pour favoriser cet apprentissage organisationnel, une certaine stabilité des acteurs est souhaitable. L’existence d’assistants MOA spécialisés, mais aussi la formation de certains chefs de projet informatiques ainsi que de certains représentants du personnel peut permettre de constituer un groupe de personnes expérimentées dans les questions de bien-être et de citoyenneté au travail et susceptibles de gagner en compétences au fur et à mesure des projets informatiques qu’elles accompagneront.