Un beau produit sans opération est un coût, pas un actif

Un logiciel ne devient un actif que lorsque quelqu'un en répond chaque jour : les releases sortent, le support est traité, le contenu reste vivant, les erreurs sont vues avant que les utilisateurs ne les voient. Un produit lancé sans personne pour l'opérer ne reste pas sagement là à conserver sa valeur. Il décline, en public, avec votre marque dessus, et chaque mois sans attention l'éloigne de l'actif et le rapproche du passif.

C'est la partie inconfortable de la construction d'un produit, celle que la plupart des propositions ne mentionnent jamais. La construction a une date de début et une date de fin. L'opération commence au lancement et ne se termine jamais. Si personne ne possède cette seconde moitié, l'argent dépensé dans la première n'était pas un investissement. C'était le prix d'une capture d'écran très chère.

Ce qu'est vraiment l'opération

L'opération n'est pas une vague ligne de maintenance au bas d'un contrat. C'est un ensemble concret de tâches, et chacune a besoin d'un nom en face :

• Quelqu'un qui surveille les logs d'erreur et les rapports de crash, et repère les problèmes avant que les utilisateurs ne les signalent
• Les releases sur les stores : nouvelles versions d'OS, nouveaux appareils, changements de règles de review, certificats qui expirent
• Un contenu qui reste vivant : nouveautés publiées, fiches mortes retirées, prix et photos à jour
• Un support traité en heures, pas en semaines, y compris les messages en colère
• Des paiements surveillés et rapprochés, des remboursements gérés, des prélèvements échoués relancés
• Les petites corrections qui n'entrent jamais dans une roadmap mais décident si un produit semble vivant ou abandonné

Comment les produits meurent en silence

Les produits meurent rarement dans une panne spectaculaire. Ils meurent en silence. Il y a un lancement, peut-être une petite fête, des captures d'écran qui circulent. Puis les mises à jour s'arrêtent. La dernière publication dans l'application date de quatre mois. La fiche sur le store indique une dernière mise à jour il y a plus d'un an, à côté de concurrents mis à jour la semaine dernière. Un bouton cassé sur un nouveau téléphone reste cassé, parce que personne ne regarde.

Les utilisateurs ne se plaignent presque jamais en partant. Ils cessent simplement d'ouvrir l'application, et le produit continue d'exister comme un lien légèrement gênant dans votre bio. Le temps que quelqu'un remarque le silence, ranimer le produit coûte plus cher que l'opérer n'aurait jamais coûté, parce que la confiance est la seule fonctionnalité qu'on ne livre pas dans une release.

Pourquoi les agences ne résolvent pas ce problème

Le modèle standard d'agence est construit autour de la livraison. Il chiffre un périmètre, le construit, le remet au client et déplace l'équipe vers le projet suivant. Ce n'est pas un défaut d'une agence en particulier : c'est la forme même du métier. Le contrat se termine exactement là où la vraie vie de votre produit commence.

L'opération est aussi un muscle différent de la construction. La construction récompense les grands sprints et les fins nettes. L'opération récompense la routine : lire les logs un mardi ordinaire, sortir une petite release que personne n'a demandée, répondre poliment à la même question de support pour la dixième fois. Les équipes montées pour livrer ont rarement les effectifs, le prix ou la motivation pour ce travail, et c'est pourquoi la remise des clés devient si souvent le début du déclin.

Comment Cazullo en est venu à opérer des logiciels

Cazullo n'a pas été créé pour vendre de l'opération. Nous avons fini par opérer des logiciels parce que nous faisons tourner nos propres produits, plus de dix aujourd'hui, et que personne d'autre n'allait en répondre. Quand votre propre nom figure sur la fiche du store, vous apprenez vite que le jour du lancement est le jour facile.

Opérer nos propres produits nous a obligés à construire pour le lendemain du lancement : un monitoring qui signale les erreurs avant les utilisateurs, des routines de release qui survivent aux mises à jour d'OS, des pipelines de contenu et des panneaux d'administration qu'une petite équipe non technique peut vraiment utiliser. Ce back-office existe parce que nous en avions besoin pour garder nos propres produits vivants. Aujourd'hui, nous offrons cette même opération à nos clients, parce que la machine tourne déjà et qu'y ajouter un produit coûte bien moins cher que de monter une opération à partir de zéro.

La réalité budgétaire

L'opération est un coût récurrent, et elle doit être planifiée dans la même conversation que la construction, pas découverte trois mois après le lancement quand la première mise à jour d'OS casse quelque chose. Nous ne vous donnerons pas de pourcentage magique, parce que la réponse honnête est que cela dépend de ce que fait le produit, du nombre d'utilisateurs et de son importance pour votre activité.

Le cadrage qui compte est plus simple : si le budget ne couvre que la construction, le budget ne couvre pas le produit. Un budget de construction seule achète un lancement, pas un actif. Prévoyez une ligne récurrente dès le premier jour, dimensionnée selon l'importance du produit, et traitez-la comme un loyer : ni optionnelle, ni une surprise.

Checklist avant de lancer

Avant de valider n'importe quel produit, mettez un vrai nom en face de chacune de ces questions :

• Qui publie la prochaine release, et la suivante ?
• Qui lit les logs d'erreur chaque semaine, avant que les utilisateurs ne signalent les erreurs ?
• Qui répond au premier e-mail de support en colère, et en combien de temps ?
• Qui garde le contenu vivant pour que le produit ne semble jamais abandonné ?
• Qui rapproche les paiements et gère les remboursements ?
• Qui réagit quand le store exige une mise à jour pour une nouvelle version d'OS ?
• Qui décide quelles petites corrections valent la peine ce mois-ci ?
• Existe-t-il une ligne budgétaire récurrente pour tout cela, convenue avant le lancement ?

Si une seule réponse est « on verra plus tard », vous n'êtes pas prêt à lancer, ou vous devriez lancer avec un partenaire qui opère. Notre recommandation est simple : traitez l'opération comme une partie du produit, contractez-la avec la construction, et acceptez qu'un produit modeste avec une opération solide bat un beau produit dont personne ne répond, à chaque fois.