Je peux adapter mes standards à votre besoin et à vos contraintes de délai. La qualité n’est cependant pas un dogme : elle consiste à faire les bons choix au regard de l’usage et de la durée de vie attendue du logiciel.
Il faut notamment distinguer trois situations :
- les prototypes ;
- les logiciels one shot ;
- la dette technique.
Un prototype sert à apprendre avant de construire. Il peut s’agir d’une démonstration, d’un POC ou d’un moyen de vérifier une hypothèse. Dans ce cas, il peut être pertinent de privilégier la vitesse et de sacrifier une partie des qualités que j’exigerais d’un logiciel destiné à durer.
Un prototype n’est toutefois pas un produit fini. Je considère qu’il doit rester clairement identifié comme tel et ne pas être déployé en production sans avoir été repris. Son objectif est de sécuriser une décision future, pas de devenir par accident le logiciel définitif.
Un logiciel one shot est, lui, conçu dès le départ pour ne pas durer. Un convertisseur de données utilisé une seule fois ou une moulinette de migration n’a pas les mêmes exigences qu’un logiciel métier appelé à fonctionner pendant dix ans. Je peux donc adapter le niveau d’investissement à cette durée de vie. En revanche, un tel logiciel n’a pas vocation à faire ensuite l’objet d’un contrat de maintenance classique.
La dette technique est différente. Il s’agit de faire consciemment un choix qui rendra le logiciel plus difficile à faire évoluer plus tard, généralement pour obtenir une fonctionnalité plus rapidement aujourd’hui. Cela peut être un choix parfaitement rationnel lorsque le délai est réellement prioritaire.
Je peux donc accepter de contracter une dette technique avec vous, à condition qu’elle soit identifiée et que nous sachions ce qu’elle implique. Une dette non déclarée finit facilement par devenir une contrainte permanente. Je préfère que nous sachions ensemble ce que nous gagnons aujourd’hui et ce que nous devrons payer demain.
En revanche, je ne crois pas qu’un délai puisse justifier n’importe quel compromis. Mon rôle est aussi de vous aider à distinguer ce qui peut être différé de ce qui mettrait réellement le logiciel en danger.
Enzo Sandré