Système de pilotage

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

Avant, aucune archive fiable. On produisait, on livrait, on recommençait. Impossible de mesurer l'effort fourni, ou de recenser ce qui avait vraiment été livré. L'information vivait dans des fichiers, et dans la mémoire des contemporains.

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

Derrière elle, trois questions concrètes :

• 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. Une activité qui n'avait pas de méthode en a reçu une, celle de la conduite de projet : des jalons, des tâches, des livrables. Sans ce découpage, l'outil n'aurait rien mesuré. Il aurait stocké, c'est tout.

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. Un rendu mal adapté à une lecture par la hiérarchie, des macros dont tout dépend, une sécurité insuffisante. Et surtout, rien à en sortir : ni indicateurs, ni rapports mis en forme.

Notion, ensuite. Mêmes limites, sur le besoin devenu central : sortir un rapport déjà mis en page, vite, sans le reprendre à la main.

Puis une application web. Elle seule répondait à deux exigences :

• 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 servir à des personnes qui ne sont pas férues d'informatique. Cette contrainte a tout décidé : une interface comprise au premier regard, et la complexité laissée de côté. Y compris des fonctions faisables, qui auraient rendu l'outil plus poussé, plus abouti. Mais d'une prise en main plus complexe.

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 a sa vue (saisie, pilotage ou direction), et n’y voit que ce qui le concerne.

Le choix technique

Une interface web, un back-end en PHP, une base MySQL. Rien d'alambiqué, et c'est voulu. Un système qui doit perdurer, et qui se transmet, doit reposer sur des bases que n'importe qui saura reprendre. La pérennité a été préférée à l'éclat du neuf.

• 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.

Conçu et cadré d'abord, puis construit avec l'assistance d'outils d'intelligence artificielle.

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

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.

Produire l'information n'était pas le problème. Le problème, c'était de choisir quoi retirer, et pour qui. Une erreur de concepteur, corrigée par un réflexe de communicant.

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

Un rapport n'est pas un déversement de données, c'est un message adressé à quelqu'un de précis.

Un outil ne se termine pas

Un défaut ne se révèle 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 qu'une activité se découpe en jalons, en tâches et en livrables, la même structure s'applique. Kheris Workspace l'a fait : la même hiérarchie, appliquée à des projets clients.

Next.js et un back-office découplé ont d'abord servi à ce site, avant qu'il ne revienne à un seul outil : c'est le dossier Du WordPress headless au thème.