Le logiciel n'est presque jamais le problème
Nous intervenons depuis des années dans des projets que d'autres ont laissés en suspens. Et il existe un schéma récurrent : quand on demande ce qui a échoué, la réponse est presque toujours d'ordre technique. L'outil était mauvais, le prestataire n'a pas livré, la technologie s'est avérée insuffisante.
Rarement exact. Dans la majorité des cas, le logiciel fonctionnait correctement. Ce qui a échoué, c'est une décision commerciale prise avant d'écrire une seule ligne de code, ou une décision organisationnelle prise après la livraison.
Voici les sept erreurs qui coûtent le plus cher, classées par ce que nous avons observé.
1. Numériser le mauvais processus
De loin la plus coûteuse.
Une entreprise possède un processus qui s'est complexifié au fil de quinze ans : un devis qui passe par quatre personnes, trois validations, deux feuilles de calcul et un email. Et elle commande un système qui reproduise exactement cela.
Le résultat est un processus aussi mauvais, mais encore plus rigide et plus cher à modifier. Avant, si quelqu'un voulait contourner une étape, il le faisait. Maintenant, c'est impossible.
Comment l'éviter : avant de définir le système, poser pour chaque étape la question : "pourquoi existe-t-elle ?" Un pourcentage surprenant d'étapes existe parce que quelqu'un qui ne travaille plus ici a eu un problème en 2014. Simplifier le processus d'abord, puis l'automatiser, coûte moins cher et donne un meilleur résultat.
2. Ne pas décider qui décide
Un projet logiciel génère des dizaines de décisions mineures : quels champs sont obligatoires, qui voit quoi, que se passe-t-il quand une donnée manque.
Si aucune personne n'a l'autorité pour décider, chacune de ces questions se transforme en réunion. Le projet s'allonge par indécision, pas par complexité technique.
Comment l'éviter : désigner un responsable ayant réellement le pouvoir de décider, même s'il consulte ensuite. Un projet avec un interlocuteur clair avance deux fois plus vite qu'un projet piloté par comité.
Andie recommande
Si dans votre organisation la personne qui décide du projet n'est pas celle qui l'utilisera, réunissez-les dès les premières réunions. La combinaison d'un directif qui décide sans utiliser et d'un utilisateur qui souffre sans décider est la recette la plus sûre pour un système que personne ne voudra.
3. Penser que la formation est facultative
On investit dans la construction de l'outil et on expédie la formation avec un email et un manuel PDF.
Ensuite l'équipe continue d'utiliser Excel "c'est plus rapide", et six mois plus tard quelqu'un conclut que le système ne fonctionnait pas. Il fonctionnait : personne n'avait appris à l'utiliser.
Comment l'éviter : budgétiser la formation comme partie du projet, la faire sur des données réelles de l'entreprise et non sur des exemples génériques, et la répéter deux ou trois semaines après, quand les vrais doutes commencent à émerger.
4. Ne pas fixer de date limite
C'est lié au point précédent et suffisamment grave pour être traité à part.
Quand le nouveau système coexiste indéfiniment avec l'ancienne méthode, c'est l'ancienne qui gagne. Toujours. Parce qu'elle est connue et parce qu'un jour de travail pressé, personne n'expérimente.
Comment l'éviter : date limite claire, communiquée à l'avance et respectée. À partir de ce jour, les nouvelles données vont uniquement dans le nouveau système. Avec une période en parallèle courte, deux ou trois semaines, pas six mois.
5. Acheter par fonctionnalités plutôt que par problème
Les comparatifs logiciels se font sur des listes de caractéristiques. Gagne celui qui a le plus de cases cochées.
Le problème est que 80 % de ces fonctionnalités ne seront jamais utilisées, et celles qui comptent vraiment sont généralement spécifiques à votre façon de travailler, c'est justement ce qui n'apparaît dans aucune liste.
Comment l'éviter : définir trois ou quatre situations réelles de votre activité et demander à ce qu'elles vous soient présentées résolues. Pas une démo générique : votre cas, avec vos données. C'est étonnant le nombre d'outils impeccables sur le papier qui s'effondrent dans cet exercice.
6. Ignorer qui va le maintenir
Un système livré n'est pas un système terminé. Il a besoin de mises à jour de sécurité, de changements quand la réglementation change et de quelqu'un qui répond quand quelque chose se casse.
Quand ce point n'est pas prévu, le prévisible se produit : le système reste sans mise à jour, accumule de la dette technique et dans trois ans il faut le refaire entièrement. Le coût de ne pas maintenir finit toujours par être supérieur à celui de maintenir.
Comment l'éviter : traiter la maintenance comme une ligne budgétaire annuelle dès le premier jour, et clarifier ce qu'elle inclut. Les questions concrètes se trouvent dans l'article sur les questions à poser avant de commander un logiciel sur mesure.
7. Ne rien mesurer avant de commencer
Si vous ne savez pas combien de temps cela prenait avant, vous ne pourrez pas prouver que c'est plus rapide maintenant. Et sans cette preuve, le projet est perçu comme une dépense et non comme un investissement, ce qui conditionne tout ce que vous voudrez faire ensuite.
Comment l'éviter : mesurer deux ou trois choses avant de toucher à quoi que ce soit. Combien de temps prend la génération d'un devis, combien d'erreurs de facturation par mois, combien de temps consacré à copier des données. Ce sont des données collectées en une semaine et elles valent de l'or quand il faut justifier la phase suivante.
Andie recommande
Conservez la mesure initiale par écrit et datée, même si c'est juste une note de quatre lignes. La mémoire est trompeuse : six mois après, tout le monde se souviendra que "de toute façon, avant non plus ce n'était pas si long". Avec le chiffre noté, la conversation sera différente.
Le schéma commun
En les considérant tous les sept, aucun n'est technique. Tous relèvent de décisions, de personnes et de discipline.
C'est aussi la bonne nouvelle : ce sont des erreurs que vous pouvez éviter avant de faire appel à quiconque et sans connaissances techniques. Un projet avec un processus simplifié, un responsable clair, une formation budgétisée, une date limite, un critère d'achat basé sur le problème, une maintenance prévue et une mesure initiale a une probabilité de réussite très élevée, presque indépendamment du prestataire.
Et inversement : sans cela, la meilleure équipe de développement du monde vous livrera quelque chose que personne n'utilisera.
Comment nous travaillons cela chez AndorraDev
Chez AndorraDev, la première conversation d'un projet ne parle pas de technologie. Elle parle du processus qui fait souffrir, de qui décide, de comment nous saurons que ça a fonctionné et de qui le maintiendra après. C'est moins spectaculaire que de montrer des écrans, et c'est ce qui détermine si le projet sert à quelque chose.
Si vous pensez numériser quelque chose et que vous voulez commencer par les bonnes questions, écrivez-nous.
