Supposons que, dans une entreprise, il ait été jugé que tel besoin doit être satisfait par un petit développement informatique, et que le programme ait reçu son précieux code projet (j’ai déjà causé de cette odyssée), par exemple VER78 (VEntes/Rapport/78ème programme développé pour ce domaine).

Les « specs »

Concrètement, dans une entreprise organisée, on écrit d’abord des spécifications (« Ce logiciel doit faire telle chose. ») et ensuite un ou des développeur(s) programme(nt).

Le processus peut être plus compliqué : expression de besoins formelle ; réunions d’arbitrage ; spécifications écrites par un key user, ou un consultant interne, ou externe, ou dossier géré de A à Z par un technico-fonctionnel solitaire ; développement en waterfall ou extreme programming ; dossiers de mise en production, d’exploitation... Mais en gros on se résume à : spécification / programme.

Pour le programme lui-même, son code, ses objets... pas de problème, le développeur sait où les trouver et déposer, il est naturellement assez ordonné[1]. De plus, en cas de négligence, la sanction est immédiate : ça ne compile plus. Les outils de gestions de version permettent également suivi et centralisation. Un programme est donc rarement perdu.

Les spécifications ne sont pas soumises à la même rigueur. Souvent, elles se matérialisent en tant que fichiers Word, dont l’éclosion s’effectue en un endroit souvent non public (disque dur personnel, clé USB, répertoire réseau privé...).

Dans les cas les plus défavorables, seul le développeur s’intéresse au code du programme, et la rédaction intervient avant l’étape d’attribution du nom VER78. Le document peut donc ne comporter qu’un titre (« Spécifications commissions sous-traitants.doc »), pas forcément explicite (« Spf comms sst TEST v7.doc »), et se trouver à peu près n’importe où sur l’intranet local…

Un cauchemar pour le petit pion de SSII qui débarque sans idée des nomenclatures et habitudes locales. C’est encore plus drôle quand les gens ne sont pas d’accord sur l’endroit où les documents doivent être déposés ; dans ce cas les chances de posséder plusieurs exemplaires des spécifications évoluant en parallèle est réel.

De l’unicité du code

J’ai donné l’exemple de VER78, sans parler d’un pépin courant : pourquoi VER79 et pas VER80 ? Qu’est-ce qui garantit que VER78 ne va pas être utilisé par quelqu’un d’autre pour un projet différent ?

Qu’on utilise un numéro (comme VER78) ou un code plus littéraire (du genre de « Nabuchodonosor »), le problème se pose rapidement (dès que l’équipe dépasse une personne — et même) : ne pas se retrouver avec deux programmes de même nom. C’est tout bête, mais dans une phase de foisonnement (installation d’un système) impliquant pléthore de consultants et développeurs, le danger est réel.

En informatique théorique, le cas est connu, il suffit de « poser un verrou » sur un numéro. Sous Oracle, on parlerait de « séquence » (à part pour le problème de non-continuité des numéros). En clair, une référence unique où se trouvent ces numéros, et qui garantit un minimum que deux personnes ne peuvent pas utiliser deux noms de programme en même temps. Mais c’est la théorie, où les programmes suivent toujours les procédures ; les humains font ce qu’ils veulent et sont faillibles.

Un collègue m’a parlé d’une technique primitive mais efficace : le classeur papier unique (le truc plat en plastique ou carton avec des anneaux métalliques et des feuilles dedans, pas un fichier Excel !). Le chef de projet ou le développeur qui a besoin de « tirer un numéro » pour nommer une brique logicielle va dans le classeur, regarde le dernier numéro ou nom utilisé, rajoute le sien, et est certain que personne ne créera le même au même moment. Inconvénient : à l’heure des bases de données réparties sur plusieurs sites, et de la sous-traitance massive aux antipodes, un classeur ne voyage ni par email ni par intranet.

Le dérivé de l’ère numérique est évident : un simple fichier Excel sur un intranet public. Encore faut-il savoir où il est sur la jungle de l’intranet réseau (a priori simple, parfois non, voir plus loin). De plus, les classeurs Excel ont le don de scissiparité, et les managers sont vite enclins à en créer d’autres pour le pilotage[2]. Le fichier unique « bête liste des programmes maison » tend très vite à évoluer en outil de mesure de la progression de projets.

La technique la plus efficace à ma connaissance est simplissime : puisque chaque développement implique la génération d’au moins un document (spécifications), autant utiliser cette base documentaire comme base pour la génération du nom du logiciel. On peut effectuer une recherche sur tous les documents intitulés VER*, trouver le dernier (VER77), pour décider de créer le VER78 — mais créer ce document n’est pas instantané, et il vaut mieux que ce code existe avant la moindre action (pour la cohérence des noms des objets à développer, pour les imputations du temps passé à écrire chaque spécification…).

Plus sûrement, utiliser les répertoires (du genre « R:\Développements\Ventes\Rapports\VER78\ »). Un répertoire se crée en deux secondes, le code VER78 est réservé même si aucun document n’a été généré, et le collègue dans l’autre bâtiment, dix secondes plus tard, avec besoin équivalent, créera son VER79.

Archi-simple. Beaucoup trop pour certains.

Notes

[1] Dans ses fichiers, pas toujours sur son bureau.

[2] Dans les gros projets, il y a des gens qui passent leur temps à remplir des fichiers Excel avec les informations d’autres fichiers Excel, ou d’informations disponibles dans l’intranet local...