Le projet a coûté ce qu'il devait coûter. Personne ne l'utilise.

D'abord, une chose à écarter

Un logiciel d'entreprise n'échoue presque jamais parce qu'il est mal programmé.

C'est contre-intuitif, et c'est pourtant ce qu'on constate en ouvrant les projets abandonnés : le code fait à peu près ce qu'on lui a demandé. Ce qui manque, c'est la réponse aux situations où la règle n'était pas claire, et ces situations représentent l'essentiel du travail réel.

Cela veut dire deux choses. Que changer de prestataire sans rien changer d'autre reproduira le même échec. Et que la part récupérable de votre projet précédent est probablement plus grande que vous ne le pensez.

Cause 1 : le projet a été cadré sur des écrans

Le cadrage a produit des maquettes. Tout le monde les a validées, parce qu'une maquette est agréable à regarder et qu'on y projette ce qu'on espère.

Une maquette montre ce que le logiciel affiche quand tout va bien. Elle ne dit rien de ce qui compte : d'où vient chaque information affichée, quelle règle produit chaque calcul, ce qui se passe quand une donnée manque, qui a le droit de modifier quoi, et ce que le système fait d'un cas qui n'entre dans aucune catégorie prévue.

Un cadrage qui ne contient que des écrans reporte toutes les décisions difficiles à la phase de construction, c'est-à-dire au moment où elles coûtent le plus cher et où elles sont prises dans l'urgence, souvent par quelqu'un qui n'a pas autorité pour les prendre.

Cause 2 : la recette n'a jamais eu de critères écrits

On a dit « on testera ». Puis chacun a testé ce qu'il connaissait, c'est-à-dire son propre usage habituel, dans les conditions habituelles.

Personne n'a testé le dernier jour du mois, la commande annulée puis rétablie, le client qui a deux adresses de facturation, l'avoir partiel, la pièce jointe manquante, la personne partie dont il faut reprendre les dossiers. Ces cas sont apparus en production, et ils ont détruit la confiance en quelques semaines.

Ce qu'il fallait, et qui se rédige avant le début : une liste de phrases vérifiables, dont chacune est vraie ou fausse sans discussion possible. Non pas « le module de facturation fonctionne », mais « une facture émise sur une commande partiellement livrée reprend uniquement les lignes livrées, et l'écran indique le reliquat ».

Tant que cette liste n'existe pas, personne ne peut dire si le projet est terminé. Et un projet dont on ne peut pas dire qu'il est terminé ne se termine pas.

Cause 3 : personne n'était responsable du côté de l'entreprise

Il y avait un sponsor, en général le dirigeant, qui suivait le projet en comité tous les quinze jours. Il n'y avait personne dont c'était le travail au quotidien.

Or un projet de logiciel opérationnel pose, chaque semaine, des questions auxquelles seule l'entreprise peut répondre : comment on traite ce cas particulier, qui valide dans cette situation, quelle règle s'applique quand les deux se contredisent, qui a raison entre ces deux services.

Sans personne pour trancher, ces questions s'accumulent, puis le prestataire finit par décider à votre place, faute de mieux. Il décide raisonnablement et il décide mal, parce qu'il ne connaît pas votre métier, et parce que ce n'est pas son rôle.

Un projet sans responsable interne disposant de temps réel et d'autorité de décision ne se termine pas. C'est la variable la plus prédictive de toutes, plus que le budget et plus que le choix du prestataire.

Le temps nécessaire n'est pas symbolique. Sur un projet opérationnel, il s'agit de plusieurs heures par semaine, y compris pour aller chercher des réponses auprès des équipes.

Cause 4 : les cas particuliers ont été repoussés

On les a écartés au cadrage, avec une formule qui revient partout : « on verra ça en phase 2 ».

Ils représentaient une petite part des volumes, et une grande part du travail. C'est structurellement le cas : le flux normal est simple, sinon il ne serait pas le flux normal. Toute la complexité d'une entreprise vit dans ses exceptions, et ces exceptions sont précisément ce qui justifie de faire construire un logiciel plutôt que d'en acheter un.

Une phase 2 qui contient les cas particuliers n'arrive presque jamais, pour une raison mécanique : la phase 1 a consommé le budget et la patience, et elle a livré un outil que personne ne peut utiliser puisqu'il ne sait pas traiter les vrais dossiers.

Les cas particuliers ne se repoussent pas. Ils se recensent au début, et ils sont ce qui détermine s'il faut construire, acheter, ou changer l'organisation.

Cause 5 : la bascule n'a jamais été décidée

Le nouvel outil a été installé, et l'ancien a continué de tourner. Officiellement pendant la transition, dans les faits pour toujours.

Ce qui se passe alors est prévisible. Comme les deux existent, chacun utilise celui qu'il maîtrise. Comme les deux sont alimentés à moitié, aucun des deux n'est juste. Comme aucun des deux n'est juste, on retourne au tableur, qui est au moins cohérent avec lui-même.

Sans date à laquelle l'ancien système s'arrête, l'ancien système gagne. Toujours. Ce n'est pas une question de conduite du changement : c'est que le double usage rend le nouvel outil objectivement moins fiable que l'ancien, tant qu'il est incomplet.

Décider cette date fait partie du projet, au même titre que le développement. Elle doit être fixée avant de commencer, et elle doit avoir des conditions écrites qui permettent de la tenir ou de la déplacer honnêtement.

Ce qui n'est pas perdu

Avant de relancer quoi que ce soit, faites l'inventaire de ce que le projet précédent a produit. La liste est presque toujours plus longue qu'attendu.

Les entretiens menés avec les équipes gardent leur valeur, même si les conclusions étaient incomplètes. Les règles écrites, quand il y en a, sont l'actif le plus précieux du projet, et souvent le seul document que personne n'a relu. Les données saisies dans la première version peuvent être reprises. Le schéma de la base, s'il a été pensé, décrit votre métier mieux que n'importe quelle présentation.

Le code est fréquemment la partie la moins précieuse de l'ensemble, et c'est la seule à laquelle on pense en disant « on a tout perdu ».

Ce qu'il faut trancher avant de relancer

Six décisions, dans cet ordre. Aucune n'est technique, et aucune ne demande de choisir un prestataire pour être prise.

1. 01Écrire les règles réelles, telles qu'elles sont appliquées aujourd'hui, exceptions comprises. Y compris celles qui ne sont écrites nulle part et que deux personnes appliquent de tête.
2. 02Recenser les cas particuliers et décider, pour chacun, s'il entre dans le périmètre ou s'il reste traité à la main.
3. 03Rédiger les critères d'acceptation : les phrases qui devront être vraies pour que ce soit terminé.
4. 04Nommer le responsable interne, avec un temps hebdomadaire explicite et l'autorité de trancher.
5. 05Fixer la date d'arrêt de l'ancien système, et les conditions qui permettraient de la déplacer.
6. 06Seulement ensuite, choisir comment le construire, et avec qui.

Les cinq premières décisions vous appartiennent et restent valables quel que soit le prestataire retenu. C'est aussi pour cela qu'elles doivent être prises avant : elles vous rendent capable de comparer des propositions, au lieu de comparer des enthousiasmes.

Ce que vous devriez exiger cette fois, de n'importe qui

Vous avez été déçu une fois. Il ne faut donc pas croire une promesse, il faut demander un moyen de vérifier. Les quatre suivants s'exigent avant de signer, et ils se refusent difficilement quand ils sont demandés.

1. 01Les critères d'acceptation écrits et acceptés par les deux parties avant le début, et le droit de constater vous-même qu'ils sont satisfaits.
2. 02Un point d'usage réel à intervalles courts, sur vos données et par vos utilisateurs, plutôt qu'une démonstration préparée.
3. 03Le comportement du système face à une donnée manquante ou contradictoire, montré et non décrit.
4. 04Ce qui vous reste si la relation s'arrête : code, accès, données, documentation, et dans quelles conditions contractuelles.

Le dernier point mérite d'être posé tôt et par écrit. Un prestataire qui l'accepte sans difficulté vous en dit long, et un qui le contourne aussi.

Nous appliquons ces quatre points à nos propres projets, et nous les écrivons dans le contrat plutôt que sur une page de site. C'est le seul endroit où un engagement a une valeur.

Le cas où la bonne réponse est de ne pas relancer

Il existe, il n'est pas rare, et il vaut mieux l'entendre avant d'engager un second budget.

Si le projet précédent a échoué parce que deux services ne sont pas d'accord sur une règle et que personne n'a tranché, aucun logiciel ne réglera cela. Un système opérationnel applique des décisions ; il ne les prend pas à votre place, et il rend le désaccord plus visible et plus coûteux.

Si le besoin réel tient dans un outil du marché et que le projet précédent visait le sur-mesure par confort, la conclusion est de choisir cet outil et d'accepter d'adapter l'organisation à ses règles.

Le sur-mesure se justifie quand vos règles sont une part de ce qui vous distingue et qu'aucun outil ne les accepte. Pas parce qu'un projet précédent a échoué.