Reste à savoir quand il « existe » vraiment. Voici les critères que nous regardons.
§1Ce qui penche vers l’étagère
- Votre besoin est partagé par beaucoup d’entreprises : comptabilité, paie, gestion de la relation client.
- Le processus est standard, et vous acceptez d’adapter votre façon de travailler à l’outil plutôt que l’inverse.
- Vous ne voulez pas maintenir de code, et l’éditeur fera évoluer le produit pour vous.
Dans ces cas, acheter coûte moins cher que construire, et la maintenance ne vous revient pas. Construire un outil qui existe déjà, c’est payer deux fois.
§2Ce qui penche vers le sur mesure
- Votre processus est la raison pour laquelle vos clients vous choisissent, et le faire entrer dans un logiciel générique reviendrait à l’appauvrir.
- Aucun outil ne le couvre sans contorsion : vos équipes exportent, recopient, contournent.
- L’outil existe, mais vous payez pour une fonction sur dix, et son prix par utilisateur devient absurde à votre échelle.
- Vos fichiers Excel partagés sont devenus des applications de fait, sans contrôle et sans historique.
Nous concevons alors des outils construits pour une tâche précise de vos équipes, connectés à vos données et intégrés à vos logiciels en place. Le code vous appartient, dans votre dépôt et sur votre infrastructure : vous pouvez le modifier le jour où la tâche change.
§3Les agents de codage déplacent la frontière
Pendant longtemps, le sur mesure était réservé aux besoins assez gros pour justifier un projet informatique. Beaucoup de tâches répétitives restaient donc sans outil, faute de budget ou de place dans la file d’attente de la DSI.
Les agents de codage ont changé l’équation. Un consultant conduit l’agent, vos équipes métiers décrivent la tâche, essaient l’outil et demandent les corrections : quelques jours suffisent là où un développement classique demandait des semaines. Le code reste relu et testé, parce qu’un agent produit du code plausible plus vite qu’il ne produit du code juste.
Construire devient donc raisonnable pour des besoins plus modestes qu’avant. À une condition : se limiter à la tâche visée. Un outil qui grossit devient un logiciel à maintenir.
§4Le vrai coût est ailleurs
Dans les deux cas, ce qui coûte, c’est l’adoption. Un outil que personne n’ouvre est un échec, qu’il ait été acheté ou construit. Trois précautions la préparent :
- choisir la tâche avec l’équipe qui la subit, sur son volume réel plutôt que sur son agacement ;
- livrer par versions courtes, utilisées tout de suite, pour découvrir les défauts tant qu’ils coûtent peu ;
- placer l’outil là où l’équipe travaille déjà, plutôt que dans un onglet de plus.
Et pour le sur mesure, une quatrième : former vos équipes à le faire évoluer. Un outil que seul son prestataire sait modifier vous rend dépendant de lui.
Une agence-conseil comme Solstice Lab peut vous aider à trancher entre achat et construction, puis à fabriquer avec vos équipes les outils qui leur manquent.
