“Plus de suivi, moins de produits”. C’est le crédo officieux des DSI (Direction des Systèmes d’Informations) modernes. Né du délire de consultants et recasés qui avaient besoin de marquer de leurs empreintes les directions informatiques, cette logique détruit la vie de ceux qui créent les logiciels que nous utilisons chaque jour.
Je suis Jean-Philippe Durand, reporter pour le magazine “Enquêtes inclusives”. Et aujourd’hui, nous allons suivre le quotidien d’Olivier, concepteur applicatif externe en poste au ministère de la Culture. Arrivé il y a 6 mois, ce collaborateur va nous présenter le parcours d’une évolution logicielle.
Olivier, l’informatique est vu par les utilisateurs comme un service ‘instantané’. Pourtant certaines actions qui paraissent évidentes nécessitent souvent des mois d’attente avant d’être disponibles dans l’application. Pouvez-vous nous expliquer le circuit de l’implantation d’une nouvelle fonctionnalité ?
Récemment, le service chargé de la supervision de la Presse française nous a demandé d’ajouter des critères de fiabilité dans les informations connues des différentes publications. Techniquement, il s’agit d’une nouvelle table, fille de la table ‘publication’, qui caractérise la crédibilité des rédactions.
Une interface permettra à l’agent assermenté d’alimenter ces informations pour chaque éditeur. Un calcul sera réalisé et remonté en automatique aux responsables pour évaluer la crédibilité et décider les aides attribuées.
Ajouter une table dans une base de données, créer un écran pour alimenter les données et écrire une requête d’extraction, ce sont des actions standards d’un développement informatique. Cela ne devrait pas vous prendre longtemps. Alors pourquoi annoncez-vous une disponibilité aux agents dans 6 mois ?
Un développement informatique ne s’arrête pas à la partie technique. Afin de s’assurer de la réussite du projet, l’organisation mise en place autour est … impitoyable. Si je vous ai résumé en quelques mots le besoin, mon travail ne s’arrête pas aux aspects techniques.
Prenons l’expression du besoin. Il est issu de la maîtrise d’ouvrage (MOA), aidée de son assistance MOA (AMOA). A la suite de réunions suivant un protocole défini par la Direction, ils ont abouti à un consensus sur les données retenus et sur les modalités de calcul.
Ma responsable me demande de détailler ces échanges dans un document de conception technique. Pour s’assurer que le besoin est bien pris en compte, je dois aussi l’identifier dans un logiciel de suivi de développement logiciel. Et pour le suivi hebdomadaire, il me faut mettre à jour la fiche projet.
Pour un développement, vous avez trois sources documentaires différentes ? Cela reste raisonnable, il faut bien justifier de votre travail auprès de votre hiérarchie.
Effectivement, mais cela ne s’arrête pas à trois sources de suivi différentes. Et cela ne s’arrête pas à la direction dont je dépends. En plus de la réunion d’équipe hebdomadaire, nous avons une réunion bi-mensuelle qui attend le même niveau d’information. Et il faut aussi réaliser un suivi hebdomadaire des actions menées.
Tous ces suivis n’assurent pas que le besoin initial est correctement implémenté. Un document recense donc les développements réalisés et les tests unitaires joués. Quand ce document est complet, je peux considérer le travail de développement complet et je peux livrer mon composant dans le circuit DevOps.
Je suppose que ce ne sont pas vos responsables qui suivent ces aspects du développement logiciel. La responsabilité en revient à d’autres directions. Non ?
J’ai oublié un autre document. Avant de livrer l’évolution, il me faut préparer un document de diffusion que j’envoie aux directions de tests (Intégration, Validation et Recette). Chaque direction veut être informée suivant le protocole qu’elle a décidé. Dans certains cas, nous devons détailler les actions de validation à réaliser.
Parfois même, nous avons à réaliser ces tests. Bien sûr, il arrive que certaines évolutions ne soient pas prises en compte sur ces environnements. Nous devons donc surveiller les déploiements sur ces environnements et contacter des directions de supervision si cela n’est pas fait.
Des demandes à faire par les différents canaux de communications, d’éventuels rapports supplémentaires. Et pour l’instant l’utilisateur final n’a pas accès à cette fonctionnalité attendue par son chef pour répondre aux exigences ministérielles.
Pour un développement informatique, vous avez un travail de suivi impressionnant. Pourtant, votre fiche de poste annonce développeur. Le propre de l’informatique n’est-il pas d’automatiser les flux d’informations ?
Encore faut-il que les responsables des différentes directions le souhaitent. Automatiser un déploiement, c’est enlever des responsabilités. Comment justifieraient-ils alors leurs positions dans l’organigramme ? Pouvez-vous couper ma dernière réflexion ?
J’ai oublié une autre part documentaire de mon action. Si nous récupérons des données d’un autre composant applicatif, nous devons demander ces accès au service en charge. De l’autre côté du développement informatique, fournir des données à des services décisionnaire ou statistiques nécessitent d’autres déclarations.
Pour quelques données à stocker, un formulaire et une sortie statistique, ce sont des dizaines de documents, suivis et rapports à réaliser. Et c’est sans compter les réunions de suivi auxquelles il faut participer. Il paraît qu’ils vont utiliser l’IA pour améliorer cela. Je pressens l’ajout d’une nouvelle couche de suivi à alimenter.
Et bien merci pour vos réponses. Je comprends mieux maintenant pourquoi les développements informatiques peuvent être aussi longs. Je vous souhaite une bonne journée.
Attendez, j’ai oublié bien d’autres aspects de mon activité qui ne sont pas liés au développement pur …