Un exemple de ce que livre une séance décision.
Refaire ou réparer : comment nous tranchons.
Ce que vous lisez ici est un exemple, écrit pour le public. Aucun client n’est en jeu. La forme — la question, ce que nous lisons, les critères, l’avis écrit — est celle d’une séance décision, 600 $ CAD, réponse en deux jours ouvrables.
La situation
Une application maison a dix ans. Elle a été écrite par une équipe qui est partie. Le fournisseur consulté pour une refonte dit qu’il faut tout reconstruire : la technologie serait dépassée, la maintenance impossible. La direction hésite : deux cent mille dollars, dix-huit mois, et le quotidien de l’entreprise qui continue de tourner sur l’outil pendant ce temps.
C’est la question la plus fréquente derrière les appels que nous recevons : faut-il refaire, ou réparer ?
Ce que nous lisons
En séance, avant l’avis, nous lisons trois choses, dans cet ordre :
- Les chiffres. Ce que l’application coûte aujourd’hui : hébergement, heures de maintenance, incidents, heures des employés perdues dans les contournements. Une refonte se justifie rarement sur la technologie ; elle se justifie, ou non, sur des dollars par année.
- Le code et les données. Pas une revue ligne par ligne : la taille réelle, les dépendances, ce qui est testé, ce qui est documenté, et surtout ce que les données savent que le code ne dit pas. Une application dont les règles d’affaires vivent dans la tête de deux personnes n’a pas le même prix qu’une application écrite.
- Les contrats. Qui détient quoi. Code source, hébergement, licences, clauses de sortie du fournisseur actuel. Une refonte qui commence sans les sources complètes recommence à zéro.
Les critères
L’avis tranche sur quatre questions, dans cet ordre :
- Le problème est-il le logiciel, ou autour du logiciel ? La moitié des refontes que nous voyons demandées remplacent un problème d’organisation par un problème de code.
- Que coûte la marche actuelle, par année, tout compris ? Le chiffre honnête, contournements compris.
- Que coûterait la marche réparée, et pour combien d’années ? Dix-huit mois de refonte pendant lesquels il faut quand même réparer, c’est payer deux fois.
- Que devient le risque ? Une refonte déplace le risque : d’un système connu et boiteux vers un système inconnu qui promet. Le risque du chantier se paie en entier avant le premier bénéfice.
L’avis, écrit
Dans l’exemple, voici l’avis tel qu’il sortirait — résumé ici, complet dans le document livré :
Réparer, et préparer la sortie. L’application remplit sa fonction et son coût annuel réel, contournements compris, reste sous la moitié du coût projeté de la refonte. Nous recommandons : (1) un plan de réparation priorisé sur les trois points qui coûtent le plus, chiffres à l’appui ; (2) la reprise des sources complètes et des données sous le contrôle direct de l’entreprise dans les trente jours ; (3) le gel de toute décision de refonte pendant douze mois, au bout desquels la question se repose avec des chiffres à jour, pas des impressions.
Ce que nous ne recommandons pas : la refonte maintenant. Elle se justifie si, dans douze mois, le coût de la marche réparée dépasse le coût annualisé de la reconstruction — la condition est écrite, il suffira de la vérifier.
Une page, les raisons derrière, et un conseil qui sait ce qu’il a approuvé.
Ce qu’il nous faut pour rendre le vôtre
Une séance de quatre-vingt-dix minutes avec les bonnes personnes autour de la table, l’accès en lecture à ce qui est vrai : les chiffres, le code, les contrats. Deux jours ouvrables après la séance, l’avis arrive par écrit. S’il n’est pas défendable devant votre conseil, il n’est pas livré.