Système de pilotage

Une équipe de six personnes, une quinzaine d'autres concernées de près, une activité continue et des échéances qui ne se déplacent pas.

Avant, le travail se faisait sans archive fiable. On produisait, on livrait, on recommençait, sans pouvoir mesurer l'effort fourni ni recenser ce qui avait réellement été livré. L'information vivait dans des fichiers et dans la mémoire des personnes présentes.

Comment faire pour qu'une activité collective ne dépende plus de la présence de ceux qui la connaissent ?

Trois questions concrètes se posaient derrière celle-là :

• ·comment savoir, à tout moment, qui fait quoi, à quelle échéance, et avec quelle importance ;
• ·comment permettre un contrôle qui porte sur des faits plutôt que sur des souvenirs ;
• ·comment faire pour que tout cela se transmette le jour où quelqu'un d'autre prend la suite.

Le cadrage avant l'outil

La première décision n'a pas été technique. Elle a consisté à appliquer une méthode de conduite de projet à une activité qui n'en avait pas : définir des jalons, des tâches et des livrables. Sans ce découpage, aucun outil n'aurait rien mesuré : il aurait seulement stocké.

C'est ce cadrage qui a rendu le reste possible. Tout ce qui suit n'en est que la mise en œuvre.

Ce que j'ai essayé, et pourquoi je l'ai écarté

Excel, d'abord. Rendu visuel inadapté à une lecture par la hiérarchie, dépendance aux macros, sécurité insuffisante, et surtout aucune sortie exploitable : ni indicateurs, ni rapports mis en forme.

Notion, ensuite. Les mêmes limites, pour un besoin devenu central : produire un rapport déjà mis en page, rapidement, sans le reprendre à la main.

Puis une application web, qui répondait à deux exigences qu'aucune des deux premières solutions ne satisfaisait :

• ·l'ouvrir de n'importe où, depuis le bureau ou en dehors ;
• ·la transmettre immédiatement, à un auditeur qui demande des éléments, ou à celui qui prendra la suite.

Cette seconde exigence est la vraie raison d'être du projet. Un outil de pilotage qui ne se transmet pas n'est pas un système : c'est un fichier personnel.

L'arbitrage de conception

Le système devait être utilisable par des personnes qui ne sont pas informaticiennes. Cette contrainte a décidé de tout le reste : rendre l'interface immédiatement compréhensible, et renoncer à la complexité, y compris à des fonctions que j'aurais su faire, et qui auraient rendu l'outil plus riche et moins utilisé.

L'application est organisée autour de deux espaces entre lesquels on bascule.

• ·Pilotage : le suivi de l'activité : ce qui est en cours, ce qui est livré, les échéances, les priorités.
• ·Rédaction : les documents produits directement en ligne, avec une visibilité réglable : privée pour l'auteur, ou partagée avec l'équipe.

S'y ajoutent trois fonctions qui font la différence entre un outil et un système : une gestion des accès, un journal qui conserve la trace de ce qui a été fait et par qui, et une corbeille qui rend les suppressions réversibles.

La gestion des accès n'est pas un réglage de confort : c'est la structure même du système. Chaque rôle dispose de sa propre vue, la saisie, le pilotage ou la direction, et ne voit que ce qui le concerne.

Le choix technique

Une interface web, un back-end en PHP, une base MySQL. Rien d'exotique, et c'est délibéré : un système qui doit durer et se transmettre a intérêt à reposer sur des briques que n'importe qui saura reprendre et maintenir. La durabilité a primé sur la modernité.

• ·Le cadrage de l'activité en jalons, tâches et livrables, préalable à toute mise en système.
• ·La conception des deux espaces, des règles de visibilité et de la gestion des accès.
• ·Le développement de l'interface et du back-end.
• ·Les mécanismes de traçabilité : journal des actions, suppressions réversibles.
• ·La génération de rapports mis en forme.
• ·La documentation du fonctionnement.

Dans quelles conditions

Environ trois mois entre la première ligne et la première utilisation réelle. Seul, en dehors du temps de travail. Des centaines d'itérations.

J'ai conçu ce système, je l'ai cadré, et je l'ai construit avec l'assistance d'outils d'intelligence artificielle. Je ne suis pas développeur de formation, et c'est le fait le plus intéressant du projet.

Le code n'est plus le verrou. La compréhension du métier l'est restée.

Trois rôles, trois usages

Le système n'a jamais été conçu pour que toute l'équipe s'en serve. Il repose sur trois rôles distincts, et c'est ce découpage qui le rend tenable :

• ·la saisie : la personne qui saisit y entre les données de l'activité ;
• ·le pilotage : j'y suis le travail au quotidien ;
• ·la direction : une vue dédiée, qui ne montre que ce dont la hiérarchie a besoin pour décider.

Élargir l'accès à tout le monde aurait multiplié les saisies concurrentes, dilué la responsabilité de la donnée et fragilisé la fiabilité de l'ensemble. Trois rôles, trois vues, une seule source d'information.

Un rapport n'est pas un export

Le défaut le plus instructif n'était pas technique. La génération de rapports produisait des informations sans pertinence pour la hiérarchie, dans une mise en page qui desservait le contenu.

Le problème n'était pas de produire l'information : c'était de choisir ce qu'il fallait retirer, et pour qui. Un rapport n'est pas un déversement de données, c'est un message adressé à quelqu'un de précis. Une erreur d'ingénieur, corrigée avec un réflexe de communicant.

J'en ai tiré un article : Un rapport n'est pas un export.

Un outil ne se termine pas

Un défaut ne se déclare qu'à l'usage. La maintenance n'est pas la queue du projet : c'en est une phase à part entière, qui commence le jour de la mise en service et ne s'arrête pas.

Un outil de pilotage n'est pas un outil collectif

Le réflexe, quand on construit un système de suivi, est de vouloir que tout le monde s'en serve. C'est une erreur. Un outil de pilotage n'a pas besoin d'être ouvert à tous : il a besoin que chaque rôle y trouve exactement ce qui le concerne : une saisie unique et responsable, un pilotage complet, une vue de direction qui ne montre que ce qui sert à décider.

Cette leçon rejoint la précédente. Ce qu'il faut retirer compte autant que ce qu'il faut montrer, pour un rapport comme pour un accès.

La maintenance se poursuit : c'est un système vivant, pas un livrable clos.

Le système est transposable, à une condition qui n'est pas technique : comprendre le métier qu'on outille. Dès lors qu'une activité peut se découper en jalons, en tâches et en livrables, la même structure s'applique. C'est ce que je souhaite voir se généraliser à d'autres activités que celle-là.

J'explore par ailleurs une refonte de l'interface avec des outils plus récents : Next.js, et un contenu piloté par un back-office découplé. Ce site en est le terrain d'apprentissage.