Cadrer un projet informatique avant le devis : la grille qui évite la dérive de coûts
Un devis informatique se signe souvent avant que quiconque ait écrit comment le travail se fait aujourd'hui. Le montant paraît solide au moment de la signature. Puis les écarts apparaissent un à un, et le dirigeant n'a plus aucun critère écrit pour réduire la portée ou arrêter.
Un devis informatique se signe souvent avant que quiconque ait écrit comment le travail se fait aujourd'hui. Le montant paraît solide au moment de la signature. Puis les écarts apparaissent un à un, et le dirigeant n'a plus aucun critère écrit pour réduire la portée ou arrêter.
Cadrer, c'est décrire le processus réel et le résultat attendu avant de demander un prix à qui que ce soit. Ça se fait sans fournisseur dans la pièce, et ça change ce qu'on achète.
Pourquoi le budget d'un projet informatique dépasse-t-il aussi souvent ?
Parce que le chiffre porte sur une solution, pas sur un besoin. Un fournisseur chiffre ce qu'on lui décrit. Si la description vient d'une salle de réunion plutôt que du poste de travail, elle décrit le processus officiel, celui qu'on raconte, pas celui qui tourne.
Le processus qui tourne contient des contournements : un fichier tenu en parallèle, une validation faite de mémoire, une exception qu'une seule personne sait traiter. Rien de tout ça n'apparaît dans un cahier des charges rédigé de bonne foi.
Ces contournements ressurgissent pendant la réalisation, sous forme d'ajouts qui paraissent mineurs pris un par un. Le budget initial ne tient pas parce qu'il chiffrait un autre travail que celui qui existe.
Ce qui se passe concrètement dans une PME
Prenons un cas hypothétique, pas un client. Une entreprise de services veut remplacer son suivi de dossiers, parce que l'information circule mal entre la personne qui prend la demande et celle qui exécute.
La direction décrit le besoin au fournisseur : un outil où le dossier se crée, s'assigne et se suit. Le devis arrive, le montant passe au conseil, le projet démarre.
Au premier essai réel, on découvre que l'assignation dépend d'une règle qui n'est écrite nulle part, que certains dossiers arrivent par téléphone et se notent à la main, et que la facturation lit un tableur qu'une seule personne entretient. Chacun de ces points devient une demande de modification.
Le dirigeant se retrouve devant un choix qu'il n'a pas préparé : payer les ajouts ou livrer un outil que personne n'utilisera. Aucune des deux réponses n'était prévue au budget.
Améliorer, relier ou faire développer : les options sur la table
La bonne option peut être d'améliorer l'outil existant, d'en relier plusieurs ou de développer ce qui manque. Le choix vient après l'observation du processus, jamais avant.
| Option | Ce qu'elle règle | Condition pour la retenir |
|---|---|---|
| Améliorer l'outil en place | Une utilisation partielle, mal paramétrée ou mal comprise | L'outil couvre déjà les étapes, mais personne ne s'en sert de la même façon |
| Relier les outils existants | L'information ressaisie d'un système à l'autre | Chaque outil fait bien sa part, le blocage est dans la circulation entre eux |
| Adopter un logiciel du marché | Un besoin courant, proche de ce que font les autres | Le processus peut s'adapter au logiciel sans casser ce qui fonctionne |
| Faire développer ce qui manque | Une étape propre à l'entreprise, qu'aucun outil ne couvre | La comparaison avec les autres options le justifie, par écrit |
Ce qui décide entre les options
Quatre questions tranchent la plupart des cas, et aucune ne porte sur la technologie.
- Le blocage est-il dans la saisie, dans la circulation de l'information ou dans la décision qu'une personne doit prendre ?
- La donnée existe-t-elle déjà quelque part, ou faut-il la créer ?
- L'exception est-elle rare, ou est-elle devenue la règle ?
- Qui porte la décision au quotidien, et cette personne a-t-elle participé à la description du processus ?
Quand l'exception est devenue la règle, aucun logiciel du marché ne tiendra sans contorsions. Quand la donnée existe déjà dans trois outils, le développement ajoute un quatrième endroit où elle sera fausse.
La grille de cadrage à remplir avant de demander un devis
Ça tient sur une page, et ça se remplit avec la personne qui fait le travail, pas avec celle qui le supervise.
- Le déclencheur : qu'est-ce qui fait démarrer le processus, et d'où arrive-t-il ?
- Les étapes réelles, écrites par la personne qui les exécute, dans ses mots.
- Les contournements : les fichiers parallèles, les rappels notés ailleurs, les vérifications faites de tête.
- La donnée d'entrée : où elle vit, qui la saisit, qui la corrige.
- Le résultat attendu, formulé de façon observable par quelqu'un d'extérieur.
- Les exceptions, et si elles sont rares ou courantes.
- Ce qui se passe si on ne change rien cette année.
- Le critère d'arrêt : à quoi on reconnaît que le projet ne vaut plus la dépense.
Un test rapide vaut pour le point deux : demande à une personne de décrire une étape du début à la fin, puis pose la même question à quelqu'un d'autre. Si les deux versions divergent, le processus n'est pas prêt à être chiffré.
:::cle Le critère d'arrêt s'écrit avant le premier dollar engagé, jamais pendant. Écrit après, il devient une négociation. Écrit avant, il devient une décision. :::
Le calcul à faire avant de comparer les devis
Un devis ne se juge pas contre l'enthousiasme de la réunion. Il se juge contre le coût de ne rien changer, calculé avec des hypothèses écrites.
Coût du statu quo sur une année = (temps par occurrence × occurrences dans l'année × taux horaire chargé) + (corrections d'erreurs × coût moyen d'une correction).
Les hypothèses s'écrivent à côté du résultat, sinon le calcul ne vaut rien :
- Le temps par occurrence se mesure sur une période réelle, pas de mémoire.
- Le taux horaire inclut les charges, pas seulement le salaire.
- Les occurrences se comptent sur une période représentative, hors pointe et hors creux.
- Les corrections se comptent à partir de ce qui est déjà tracé, pas à partir d'une impression.
- Le temps libéré ne devient une économie que s'il est réaffecté à quelque chose de nommé.
Ce montant donne une borne. Un devis qui la dépasse largement demande une justification qui ne tient pas dans une promesse.
Quoi faire lundi matin
Choisis un seul processus, celui qui revient le plus souvent dans les plaintes internes. Assieds-toi à côté de la personne qui l'exécute et fais remplir les huit points de la grille, sans corriger ses mots.
Écris ensuite le critère d'arrêt et le calcul du statu quo avec ses hypothèses. Ces deux pages partent aux fournisseurs avant toute demande de prix, et la même page part à tout le monde.
On commence par comprendre le processus et les contournements actuels : c'est ce qui permet de dire, chiffres en main, si le sur mesure se justifie ou si l'outil déjà payé fait l'affaire.
Questions fréquentes
Comment cadrer un projet informatique avant de demander un devis ?
Le cadrage consiste à écrire le processus réel avant de parler de solution. On note le déclencheur, les étapes dans les mots de la personne qui les exécute, les contournements en place, la source de chaque donnée, le résultat attendu et les exceptions. On ajoute ce qui se passe si rien ne change, puis le critère qui permettra d'arrêter. Ce document part aux fournisseurs, il ne se rédige pas avec eux.
Faut-il améliorer l'outil existant ou faire développer sur mesure ?
Ça dépend de l'endroit où le processus bloque. Si l'outil couvre déjà les étapes mais que chacun s'en sert autrement, le problème est d'usage et de paramétrage. Le sur mesure n'est pertinent que si la comparaison avec les autres options le justifie, et cette comparaison s'écrit avant d'engager la dépense.
Comment éviter la dérive de coûts d'un projet informatique en PME ?
La dérive vient presque toujours d'un écart entre le processus décrit au fournisseur et le processus qui tourne. Deux protections tiennent : décrire le travail au poste de travail avant le devis, et fixer par écrit le critère d'arrêt. Sans ce critère, chaque ajout se discute isolément et le total échappe à la décision.
Qui doit participer au cadrage d'un projet informatique ?
La personne qui exécute le processus au quotidien, celle qui reçoit le résultat en aval, et le dirigeant qui portera la décision budgétaire. Sans la première, les contournements restent invisibles. Sans la deuxième, on automatise un travail qui devra être repris plus loin dans la chaîne.