Les patates sont pour moi les schémas sommaires que dessinent tous les consultants lorsqu’ils illustrent les flux dans une entreprise.
Ces dessins ont pour but de décrire les processus qui serviront de modèle à la mise en place d’un logiciel « intégré ». Cet article est une réflexion sur le risque que présente ce type de démarche.
Ainsi le consultant est le roi des patates dont il abreuve ses clients. Mon estimé collègue hollandais lie malicieusement ces démarches à un tableau de Van Gogh peint en 1885, « De Aardappeleters » en français, « les mangeurs de pommes de terre ».
La question de la description fonctionnelle d’une organisation est complexe et nécessite un langage commun afin que le fournisseur et le client comprennent la même chose.
Chacun a appris qu’un projet informatique ne devait démarrer que sur la base d’un cahier des charges.
Pour les logiciels développés « sur mesure », les spécifications écrites sont indispensables afin de limiter les risques de dérives fonctionnelles.
Un progiciel est, à priori, moins sujet à ces risques dérives car c’est l’équivalent de la « confection » pour laquelle seules quelques retouches seront possibles.
Dans la réalité, il est rare de tomber sur un tel document. Tout le paradoxe est là, si personne ne songerait à construire une maison sans un plan et sans un descriptif de construction, la pratique est courante dans les projets informatiques.
Cependant il faut admettre que la spécification d’un logiciel est beaucoup plus complexe que le plan d’une maison. En effet, un bâtiment est un élément statique et tangible alors que le logiciel s’inscrit dans une logique de flux dynamiques et d’événements asynchrones, le tout évoluant dans une grande abstraction. Par conséquent, le cahier des charges classique est un outil peu adapté qui peine à décrire cette complexité; de plus, le client a rarement une idée précise sur ce qu’il souhaite.
La question de la méthode a été abordée dans un précédent article et j’invite ceux qui s’y intéressent à lire la note intitulée « maquette et optimisme, un risque important ».
De spécification complète et figée, nous sommes arrivés à une époque où on ne spécifie plus du tout. La règle semble être de faire quelques schémas de principe sur un tableau blanc. Cela se résume à dessiner quelques blocs (mes fameuses patates) agrémentés de flèches qui les relient. La promesse et l’espérance est que la mise en œuvre de ces quelques concepts simples se fera par paramétrage sur le progiciel « de confection ».
Le schéma fictif suivant n’est probablement pas inconnu de tous ceux qui ont à formaliser la définition de flux fonctionnels :
Ainsi lors de telles séances « patates » tous les participants trouveront un accord de principe sur des articulations qui semblent « logiques ».
Si cette représentation a le mérite de rendre tangible quelques grands concepts, elle ne dit rien des séquences et autres traitements des flux.
Souvenez-vous qu’il n’y a pas de solutions miraculeuses en informatique. Par exemple, si un progiciel est un raccourci dans la réalisation il ne permet en aucun cas de s’affranchir d’une spécification.
« Ce qui se conçoit bien s’énonce clairement », par conséquent, ne vous contentez pas d’un vague schéma et ayez une idée précise de ce qui est attendu et comment cela doit fonctionner.
Attendre d’un progiciel qu’il structure une activité est un oreiller de paresse qui peut s’avérer dévastateur pour l’organisation.
De plus, toute solution va nécessiter des décisions dans la façon de procéder. Ces décisions seront prises sur des arbitrages et des pesées d’intérêt.
Conservez précieusement une trace écrite de vos arbitrages. Au mieux les traces permettent de se souvenir le pourquoi du comment lorsque de nouvelles options s’appuient sur vos décisions antérieures. Au pire si le projet entre dans une phase de difficulté, vous pouvez espérer capitaliser sur l’expérience. Enfin, en cas de litige, vous vous disposerez de sources fiables.
L’informatique est la branche la plus complexe des sciences de l’ingénieur. Malheureusement c’est celle pour laquelle on attaque des réalisations avec le plus de désinvolture.
J’ai eu l’occasion d’arbitrer plusieurs projets informatiques dans l’impasse, les causes ont peu ou prou été les mêmes. Je retiens les causes suivantes :
- Objectifs peu clairs et non partagés
- Lacunes de spécifications
- Optimisme
- Laxisme dans le suivi et la coordination
- Non implication de la direction
Tous les projets abordés de cette manière ne sont pas des échecs. En revanche j’observe que tous les projets en échecs ont été abordés ainsi. La prise de risque est donc conséquente.
En tout état de cause, doutez et chalengez les vendeurs et les consultants qui promettent la lune sur la base de quelques schémas car le procédé frise le charlatanisme.
Fort de ces constats de bon sens, il serait dommage d’échouer et que l’issue votre projet devienne aussi sombre que le tableau de Van Gogh « De Aardappeleters ».
© Pascal Rulfi, mars 2016
Téléchargez l’article : De Aardappeleters