Une application avec authentification, gestion des rôles, dépôt de fichiers et notifications se construit aujourd'hui en une fraction du temps qu'elle demandait il y a deux ans. Ce n'est pas un argument commercial, c'est l'état des choses, et vous le verrez dans une offre sur deux.

Ce qui n'a pas raccourci : quelqu'un doit exploiter l'application. Quelqu'un doit la maintenir à jour quand une interface change. Quelqu'un doit être joignable quand elle s'arrête un jeudi après-midi. Quelqu'un doit répondre si des données sont perdues ou fuitent. Et quelqu'un doit avoir réellement lu le code avant sa mise en production chez vous.

Ces postes ne sont pas devenus moins chers. Ils sont simplement plus visibles, parce que la partie construction a fondu devant eux.

Vous n'achetez plus des heures de développement. Vous achetez une responsabilité d'exploitation – et c'est précisément ce qui ne figure pas dans la plupart des offres.

Si une offre ne clarifie pas ces cinq points d'elle-même, son prix n'est pas comparable, aussi détaillé que soit le descriptif.

• Qui exploite le résultat ? L'application tourne-t-elle chez vous, chez le prestataire ou chez un tiers ? Qui installe les mises à jour, et à quelle fréquence ? Une offre sans modèle d'exploitation ne couvre que la moitié du sujet.
• Que se passe-t-il en cas de panne ? Qui est joignable, dans quel délai, et à quel coût ? « Support en régie » n'est pas une réponse : c'est le report de la question au jour où cela brûle.
• Qui a lu le code ? Un code généré fonctionne souvent du premier coup et se disloque à la deuxième modification. Demandez qui a relu le résultat et ce que cette relecture a donné. La réponse vous en dira plus que le portfolio.
• Comment en sortez-vous ? À qui appartient le code, où sont vos données, et sous quel format récupérez-vous les deux en cas de changement de prestataire ? Cette question se pose avant le contrat, pas après le litige.
• Qu'est-ce qui est explicitement exclu ? Formation, reprise des données de l'ancien système, raccordement à votre comptabilité, accessibilité, documentation RGPD. Un prestataire qui fournit cette liste de lui-même a déjà mené un projet jusqu'au bout.

Nous avons automatisé notre propre production d'articles et y avons vécu quelque chose qui vaut pour tout projet logiciel : produire était la partie simple. Le temps s'est perdu au raccordement – des droits de fichiers qui ne produisent aucune erreur, seulement une image absente. Un fichier de configuration qui remplace silencieusement un réglage du système, après quoi des pages entières restent vides sans la moindre erreur affichée.

Aucun de ces problèmes n'aurait été visible dans une offre. Tous auraient coûté plusieurs jours à quelqu'un qui ne connaît pas le système – voire le projet entier.

Une offre qui ne chiffre que la construction ne supprime pas ces journées, elle les dissimule. Elles réapparaissent plus tard, en avenant ou en arrêt de production.

Le fait qu'une chose puisse être reconstruite rapidement n'est pas une raison de la reconstruire. Trois situations dans lesquelles nous le déconseillons :

• Votre solution actuelle tourne et personne ne se plaint. L'erreur la plus fréquente après un bon entretien de vente. Remplacer un système qui fonctionne vous coûte la réappropriation par vos équipes – et aucun prestataire ne la paie.
• Le processus sous-jacent est en train de bouger. Un logiciel fige un déroulement. Si le déroulement bouge encore, vous construirez deux fois. D'abord stabiliser le processus, ensuite le numériser.
• Personne chez vous ne peut juger le résultat. Alors la vitesse n'est pas un avantage mais un risque : vous obtenez plus vite quelque chose dont vous ne pouvez pas évaluer la solidité. Dans ce cas, recrutez d'abord quelqu'un qui contrôle, pas quelqu'un qui construit.