Réalisation
Importance de la phase pour le dialogue social
Cette phase concerne essentiellement la MOE, mais la traduction numérique de la vision logique globale produite à la phase Conception conduit forcément à des interprétations, des adaptations en réponse à des contraintes (techniques, budgétaires, de planning…) qui peuvent impacter les réponses données aux besoins exprimés, notamment ceux concernant le bien-être et citoyenneté au travail.
L’implication des porteurs des demandes en matière de bien-être et citoyenneté au travail doit donc rester constante tout au long de la phase.
Dans le cas de l’achat d’un logiciel sur étagère (progiciel), un cycle spécifique est suivi (voir plus loin)
La phase ici décrite correspond au développement d’un logiciel spécifique.
Cette phase concerne principalement la MOE.
Autres dénominations : étude technique et réalisation (qui sont parfois deux phases distinctes), développement, exécution.
- Approches agiles
Si l’ensemble du projet n’est pas géré en approche agile, il peut être décidé en début de cette phase de mener la suite en mode agile.
Il est alors important que les porteurs des demandes en matière de bien-être et citoyenneté au travail prennent conscience des spécificités des approches agiles : voir Approches agiles
Objectifs de la phase
Produire le logiciel (objet du projet) dans une version testée sur le plan technique par l’équipe de développement.
Dans le cas de l’achat d’un progiciel, paramétrer ce dernier avec l’équipe du prestataire.
- Cas de l’achat d’un progiciel
Voir détails.
Nota : les enjeux pour le haut management.
Attention portée essentiellement aux coûts et délais, qui doivent rester dans le prévisionnel.
Entrées usuelles de la phase / sorties usuelles de la phase
Entrées
Cahier des charges pour la réalisation, avec l’ensemble des modélisations
Sorties
L’application objet du projet testé (par l’équipe de développement) pour vérifier son adéquation aux spécifications techniques (interne équipe MOE).
Procès-verbal de recette technique.
Intégration technique du logiciel dans une architecture générale testée (interne équipe MOE).
Documentation interne MOE.
Documentation externe.
Acteurs et instances impliqués
Le chef de projet.
Un ou des business analysts (équivalents Assistants à la MOA).
Des développeurs, dont un ou des spécialistes des tests techniques (= des développeurs orientés tests), avec éventuellement un responsable des tests (selon l’importance du projet).
- Point de vigilance
Les Assistants MOA (et/ou les acteurs métier) spécialisés dans les thématiques du bien-être et citoyenneté au travail doivent être consultés pendant cette phase.
Contenu et déroulé de la phase
Deux sous-phases : étude technique et développement.
Étude technique (ne concerne que la MOE) : optimisation structure physique des données, des volumes. Préparation du développement : élaboration des traitements (dossier programmes), définition des normes techniques.
Développement : programmation, tests internes, test d’intégration, élaboration de jeux d’essai pour la phase Recette.
- Point de vigilance : IHM
La réalisation concrète des IHM va permettre d’en détailler très concrètement le contenu. Par ailleurs certaines contraintes techniques non anticipées peuvent conduire à des modifications des IHM telles que prévues à la phase Conception & planification.
Les porteurs des demandes en matière de bien-être et citoyenneté au travail doivent être informés du détail des IHM et des modifications éventuelles et doivent évaluer le respect des besoins exprimés (voir notamment les exigences en « Autonomie » proposées).
- Point de vigilance : aide à la décision (dont tableaux de bord)
Même remarque que ci-dessus concernant les IHM (voir notamment les exigences en « Décision & système de pilotage »).
Informations habituellement diffusées/traitées
Essentiellement indicateurs de suivi du projet (KPI) sur les coûts et les délais.
Éventuellement dictionnaire des données.
Nota sur les dictionnaires de données1 : « référentiel centralisé de l’information sur les données, leurs signification, relation avec d’autres données, leurs origine, utilisation et format ».
Ils peuvent faire l’objet de normes (ex. norme ISO 20022 pour les institutions financières2 ), mais dans certains domaines, ils peuvent ne pas exister, les objets métier n’étant alors pas assez précisément définis.
- Information à recevoir
Le ou les dictionnaires de données doivent pouvoir être consultés par les porteurs des demandes en matière de bien-être et citoyenneté au travail.
- Point de vigilance
L’absence de dictionnaire de données peut poser problème en particulier pour les outils d’aide à la décision (dont les tableaux de bord). En effet, dans ce cas, la qualité des données et des indicateurs est difficile à évaluer, faisant courir de risque, à l’organisation et aux salariés, de décisions prises sur la base de données très peu fiables voire fausses.
Cas de l’achat d’un logiciel sur étagère (progiciel)
Rappel : la décision d’achat est prise soit en fin de Conception, soit en fin de phase de Cadrage.
L’achat d’un logiciel sur étagère suit en principe les procédures d’achat de l’organisation (ex. : exigence de trois devis au moins, de critères de choix transparents, règlement des marchés publics…).
Une première étape est celle de la recherche des logiciels proposés sur le marché et susceptibles de répondre au besoin exprimé. On regarde ce qui existe dans le secteur d’activité macro, puis on va rechercher les spécificités des logiciels du secteur, les fonctionnalités assurées et celles qui ne le sont pas.
Cette recherche permet de retenir un premier ensemble d’offres et de partenaires potentiels.
Le Cadrage et éventuellement la Conception ont permis de définir un ensemble de besoins hiérarchisés selon leur caractère indispensable ou optionnel. Une grille d’analyse des propositions peut ainsi être établie, complétée de critères portant sur le partenaire (solidité de l’entreprise, compétences avérées, expérience, clients connus…). Une liste plus réduite de partenaires est établie, sur la base de ces critères. L’appel d’offre est envoyé à ces prestataires, et l’une des offres est retenue sur la base des critères définis.
Le choix d’un prestataire fait, la phase de Réalisation proprement dite va porter sur :
- un affinage des besoins et en général leur ajustement aux possibilités du logiciel choisi
- le choix précis des modules (et fonctionnalités) qui feront l’objet de la commande
- en général une personnalisation (customisation) des fonctions, structures de données, IHM, états de sortie…
- en général une reprise des données existantes.
Notons que les phases de Livraison/Recette et de Déploiement sont comparables à celles concernant un logiciel développé spécifique.
- Information à recevoir : achat d’un logiciel sur étagère
La procédure de choix du logiciel sur étagère doit être transparente et connue des porteurs des besoins en matière de bien-être et de citoyenneté au travail.
- Procédures du dialogue social : achat d’un logiciel sur étagère
Les critères de choix du logiciel et éventuellement de l’intégrateur doivent faire l’objet d’un dialogue social.
Ces critères doivent être en cohérence avec les besoins exprimés en matière de bien-être et citoyenneté au travail.
- Information à recevoir : fonctionnalités des progiciels
Les porteurs des besoins en matière de bien-être et de citoyenneté au travail doivent disposer d’une description précise des fonctionnalités offertes par chacun des progiciels retenus. Ils doivent les comparer aux besoins exprimés en matière de bien-être et citoyenneté au travail.
- Information à recevoir : modification des processus de travail
Le degré et le type de modification des processus de travail actuels par chacun des logiciels sur étagère considérés doivent être analysés et évalués.
Ils doivent constituer l’un des critères de choix du logiciel à acquérir.
- Point de vigilance : IHM, tableaux de bord …
La personnalisation des IHM, des tableaux de bord… doit répondre aux besoins exprimés en bien-être et citoyenneté au travail (voir les catégories de besoin thèmes Autonomie et Décision & système de pilotage).
- Aides ISIDOR
Pour une liste des questions à se poser sur les IHM, voir ISIDOR, Grille d’analyse Autonomie.
Pour une liste des questions à se poser sur les tableaux de bord, voir ISIDOR, Grille d’analyse Système de pilotage & Décision.
