Un prototype n'est pas un produit

La démonstration est trompeuse. En deux heures, avec un assistant, vous obtenez quelque chose qui fonctionne. C'est réel, et c'est le début du travail, pas la fin.

Ce qui sépare les deux

Un prototype fonctionne sur le cas nominal, sur votre machine, avec vos données, pendant que vous le regardez.

Un outil qu'on confie à d'autres doit en plus :

• traiter les entrées inattendues sans casser ;
• ne pas perdre de données en cas d'interruption ;
• dire clairement ce qui s'est mal passé ;
• fonctionner sur d'autres machines que la vôtre ;
• rester compréhensible dans six mois ;
• ne pas exposer de secrets ;
• pouvoir être corrigé sans tout casser.

Chacun de ces points représente plus de travail que le prototype lui-même. C'est la raison, souvent mal comprise, pour laquelle un produit prend des années alors que sa démonstration prend un week-end.

La bonne ambition

Pour la plupart des lecteurs de cette formation, la cible réaliste et utile est un outil interne : quelque chose que vous et deux ou trois personnes utilisez, sur un besoin précis, avec des données que vous maîtrisez.

C'est atteignable, c'est rentable, et cela n'exige pas de devenir développeur.

Viser une application grand public sans compétence technique ni équipe est un pari, pas un plan.

Le test avant de construire

Trois questions, dans cet ordre :

Un tableur suffirait-il ? Dans la majorité des cas, oui. Un tableur bien construit, avec des formules et des listes déroulantes, résout plus de problèmes qu'on ne le croit, sans code, sans hébergement et sans maintenance.

Un outil existant le fait-il déjà ? Cherchez sérieusement avant de construire. Un abonnement à quelques euros par mois coûte moins cher que votre temps de développement et de maintenance.

Combien de fois par semaine cet outil servira-t-il ? En dessous de quelques usages hebdomadaires, la maintenance dépassera le gain.

Si vous répondez « non, non, souvent », construisez. Sinon, ne construisez pas : c'est la décision la plus rentable de cette formation.

Le coût de maintenance

C'est le poste que personne ne compte, et il ne disparaît jamais.

Un outil vivant demande : des mises à jour de dépendances, des corrections quand un service tiers change, des adaptations quand le besoin évolue. Comptez plusieurs heures par mois pour un outil réellement utilisé.

Un outil construit puis abandonné devient un piège : quelqu'un s'en sert encore, personne ne sait le réparer.

Ce que l'assistance change réellement

Elle divise le temps de production du code. Elle ne change ni la conception, ni les tests, ni la sécurité, ni la maintenance — c'est-à-dire l'essentiel du coût d'un logiciel.

Un débutant assisté produit du code qui a l'air correct plus vite qu'avant. C'est un progrès, et c'est aussi un risque nouveau : produire vite ce qu'on ne sait pas relire.