Livré ne veut pas dire terminé
Il y a un moment que tous nos clients vivent de la même façon. Le système est remis, l'équipe se félicite, les captures d'écran circulent dans le groupe de la direction, puis le lendemain matin, à huit heures, une vendeuse ou une secrétaire médicale ouvre l'application et saisit une vraie commande, avec un vrai client et un vrai montant. C'est précisément à cette minute que le logiciel cesse d'être une démonstration pour devenir un outil de travail, et c'est aussi à cette minute que commencent les questions auxquelles personne n'avait pensé pendant la recette.
Cette période de rodage se mesure, ce qui veut dire que vous pouvez la budgéter au lieu de la subir. Le premier mois après la mise en service génère en général entre 25 et 40 messages de support, parce que chaque personne découvre son cas particulier au même moment. Le deuxième mois tombe autour de 16 messages, le troisième autour de 9, et à partir du quatrième mois cela se stabilise entre 4 et 8 par mois lorsque les équipes ont été correctement formées. Un premier mois bruyant est donc parfaitement normal, ce n'est pas le signe que le projet a échoué, c'est le signe que le système est réellement utilisé.
Reste à comprendre ce que couvre la garantie, parce que le mot rassure souvent plus qu'il n'explique. La plupart des contrats de développement incluent 30 à 90 jours de corrections gratuites pour ce qui a été mal construit : un calcul faux, un bouton qui ne fait pas ce que le cahier des charges annonçait, une page qui plante dans un cas précis. En revanche, la garantie ne couvre pas les nouvelles demandes, même minuscules, elle ne couvre pas les erreurs de saisie de vos équipes, et elle ne couvre pas les changements qu'une société extérieure vous impose, par exemple votre prestataire de paiement qui modifie sa façon de se connecter.
Une fois la garantie terminée, la question devient très simple et très concrète : quelqu'un doit être responsable de ce système, tous les mois, pendant des années. Cet article répond à deux choses seulement, qui doit être ce quelqu'un et combien cela coûte vraiment. Chez Linkysoft, nous livrons des systèmes puis nous les gardons en vie, donc les chiffres qui suivent viennent de ce que nous constatons sur nos propres projets et sur ceux que nous reprenons à d'autres équipes.
Les quatre travaux qui ne s'arrêtent jamais
La maintenance n'est pas une activité, c'en est quatre, et elles n'ont pas grand-chose à voir entre elles. Il y a réparer ce qui est cassé, suivre le monde extérieur qui bouge sans vous demander votre avis, améliorer ce que les utilisateurs réclament, et empêcher les problèmes d'arriver. Les trois dernières sont invisibles quand elles sont bien faites, ce qui explique à peu près tous les malentendus budgétaires que nous rencontrons.
Un exemple de chacune, pris chez de vrais clients. Réparer, c'est le rapport de fin de journée qui affiche un total faux parce qu'un avoir n'est pas déduit. Suivre le monde extérieur, c'est votre prestataire de paiement qui annonce la fin de son ancienne connexion et vous laisse quelques mois pour basculer. Améliorer, c'est la réception qui demande un deuxième champ de téléphone parce que la moitié des patients donnent le numéro d'un proche. Prévenir, c'est la base de données qui a grossi tranquillement pendant dix mois jusqu'à ce que la recherche d'un client prenne quatre secondes au lieu de deux dixièmes.
Voici la surprise, et elle change toute la conversation : sur un mois de maintenance ordinaire, environ 30 % du temps part dans les corrections et les questions des utilisateurs, tandis que 40 % va au maintien en condition, c'est-à-dire les mises à jour, la surveillance, les sauvegardes et les correctifs de sécurité, 20 % aux petites améliorations et 10 % au reporting et à la planification. Autrement dit, les deux tiers du budget servent à des choses que personne ne remarque, sauf le jour où elles n'ont pas été faites.
Cette répartition compte énormément pour la discussion budgétaire, parce qu'un client qui croit que maintenance égale bugs en déduit très logiquement qu'un système bien construit n'a presque besoin de rien. Il signe donc un contrat minimal, puis découvre sa première année avec un mélange de surprise et de colère. Poser la répartition dès le départ évite exactement cette conversation.
Le monde change même si vous ne touchez à rien
C'est le point central de cet article : un logiciel se dégrade même à l'arrêt, parce que tout ce qui l'entoure avance. Les navigateurs se mettent à jour environ toutes les quatre semaines, et les systèmes d'exploitation des téléphones sortent une version majeure par an. Votre code n'a pas bougé d'une virgule, mais le terrain sur lequel il est posé, lui, a changé de forme.
La règle qui surprend tous les clients concerne les magasins d'applications. Apple et Google relèvent chaque année les exigences minimales de construction, ce qui veut dire qu'une application laissée intacte pendant 12 à 18 mois demande en général entre 20 et 60 heures de travail avant de pouvoir être republiée, alors que rien n'a changé pour l'utilisateur. C'est une dépense qui n'apporte aucune fonctionnalité nouvelle, et c'est pourtant la condition pour rester présent, donc si votre projet comporte une application mobile, inscrivez cette ligne au budget avant même de la faire construire.
Le même mécanisme existe côté serveur. Le moteur sur lequel tourne votre système, autrement dit le langage et sa version, bénéficie d'une durée de support d'environ deux à trois ans, après quoi il ne reçoit plus de correctifs de sécurité. Prévoyez donc une montée de version planifiée tous les deux à trois ans, comptez 15 à 60 heures selon la taille du système, et faites-la à la date que vous avez choisie plutôt que dans l'urgence, car une migration préparée coûte une fraction d'une migration décidée un vendredi soir parce que l'hébergeur coupe l'ancienne version.
Il y a aussi tous les services extérieurs auxquels votre système parle. Les passerelles de paiement, les transporteurs et les fournisseurs de SMS retirent régulièrement leurs anciennes connexions, et ils préviennent en général 6 à 12 mois à l'avance, par courriel, à l'adresse technique enregistrée sur le compte. Rien de dramatique, sauf que quelqu'un doit lire ces courriels, et dans la majorité des PME dont nous reprenons le système, cette adresse n'est plus relevée par personne depuis des mois.
Terminons par un détail bon marché et brutal : le certificat de sécurité, ce petit cadenas dans la barre d'adresse. Un certificat gratuit dure 90 jours et se renouvelle tout seul, un certificat payant dure généralement un an, et la vérification prend quelques minutes. Un seul certificat expiré met la totalité du site hors ligne, pour tous les visiteurs, à la même seconde, avec un avertissement rouge que vos clients interprètent comme une tentative d'arnaque.
Ce que coûte vraiment l'entretien, calcul à l'appui
La règle empirique du secteur est simple, et elle mérite d'être posée avec son calcul plutôt que citée en l'air. L'entretien annuel d'un logiciel sur mesure représente en général 15 à 25 % du coût de construction initial. Un système facturé 30 000 USD demande donc entre 4 500 et 7 500 USD par an, soit à peu près 375 à 625 USD par mois. Appliquez le même calcul à votre propre montant, c'est la façon la plus honnête de vérifier si une proposition tient debout.
Ce qui pousse un projet vers le haut ou vers le bas de cette fourchette tient à quatre facteurs que vous pouvez évaluer vous-même en quelques minutes : le nombre de services extérieurs auxquels le système est raccordé, puisque chacun peut changer sans vous demander votre avis, le fait que de l'argent circule ou non à l'intérieur, la présence éventuelle d'une application mobile avec son cycle annuel de remise en conformité, et enfin le nombre de personnes qui s'en servent tous les jours, car cent utilisateurs rencontrent des situations que cinq utilisateurs ne croiseront jamais. Un outil interne utilisé par cinq personnes, sans paiement et sans mobile, vit très bien à 15 %. Une boutique qui encaisse, se synchronise avec un transporteur et possède une application se situe à 25 %, et parfois un peu au-delà.
À cela s'ajoutent les frais de fonctionnement, qu'il faut annoncer séparément pour que rien ne se cache dans la facture. L'hébergement d'un système de PME coûte en général 40 à 200 USD par mois, le nom de domaine 10 à 40 USD par an, le compte développeur Apple 99 USD par an et celui de Google 25 USD une fois pour toutes. Une fois les postes annuels ramenés au mois et ajoutés à l'hébergement, les coûts de machine seuls représentent donc environ 50 à 215 USD par mois, avant la moindre heure humaine.
Le meilleur réflexe, pour finir, consiste à traduire ces pourcentages en heures, parce que l'heure est la seule unité réellement comparable d'un prestataire à l'autre. Un forfait de 500 USD par mois achète, dans la plupart des marchés, entre 4 et 10 heures de travail qualifié. Demandez donc systématiquement combien d'heures contient le prix qu'on vous propose, et si votre interlocuteur ne sait pas répondre, vous venez d'apprendre quelque chose d'important sur la suite de la relation.
Qui le garde vraiment en vie : quatre options honnêtes
Première option, l'équipe qui l'a construit, sous forme de forfait mensuel. C'est la plus rapide, tout simplement parce qu'elle connaît déjà le système et n'a rien à réapprendre, et c'est en général celle qui donne les meilleurs délais sur un incident sérieux. Sa faiblesse, disons-la franchement, c'est la dépendance à un seul fournisseur, donc exigez un contrat qui vous laisse partir avec absolument tout : le code, les comptes et la documentation.
Deuxième option, un indépendant d'astreinte. Comptez souvent autour de 12 000 USD par an pour une disponibilité réelle, ce qui revient moins cher à l'heure, avec un risque évident : une seule personne tombe malade, part en vacances ou change de métier, et toute la connaissance du système s'en va avec elle. Cette formule fonctionne bien quand le système est stable et que la documentation est véritablement à jour, beaucoup moins quand tout repose sur la mémoire d'une seule tête.
Troisième option, recruter en interne. Dans beaucoup de marchés, le coût réel d'un développeur confirmé se situe entre 35 000 et 90 000 USD par an une fois tout compté, charges, matériel et temps d'encadrement compris, ce qui n'a de sens que si le système évolue toutes les semaines et se trouve au centre de la façon dont l'entreprise gagne sa vie. En dessous de ce niveau d'activité, vous payez surtout de l'attente.
Quatrième option, ne rien faire et appeler quelqu'un quand ça casse. Disons-le sans détour : c'est un choix parfaitement légitime pour un petit outil interne sans enjeu, et c'est un mauvais choix pour tout ce qui encaisse de l'argent, parce que l'intervention de sauvetage coûte toujours plus cher que l'année d'entretien évitée, sans compter les journées de vente perdues pendant qu'un inconnu essaie de comprendre un système que personne n'a documenté. Nos applications web métier sont livrées avec cette conversation, pas après.
Le dossier de transfert à posséder avant la facture finale
Voici une liste que vous pouvez imprimer et cocher point par point avant de régler le dernier acompte, car une fois la facture payée, l'attention de tout le monde retombe et ces demandes deviennent nettement plus difficiles à obtenir.
- Le nom de domaine et sa configuration DNS, c'est-à-dire le carnet d'adresses qui indique à Internet où se trouve réellement votre site, le tout dans un compte au nom de votre société.
- Le compte d'hébergement ou de cloud, détenu par l'entreprise et non par le prestataire.
- Le code source, déposé dans un dépôt que vous contrôlez, un dépôt étant l'entrepôt en ligne qui conserve le code avec l'historique de chaque modification faite depuis le premier jour.
- Les accès à la base de données, rangés dans un gestionnaire de mots de passe de l'entreprise et pas dans un fil de discussion.
- Un relevé écrit de chaque licence achetée pour le projet, avec son prix et sa date de renouvellement.
Il y a un point qui piège presque toutes les petites structures : chaque compte tiers, c'est-à-dire le paiement, l'envoi de courriels, les SMS et les cartes, doit être ouvert sur une adresse électronique de l'entreprise et jamais sur l'adresse personnelle d'un développeur. Ces comptes contiennent votre argent et les données de vos clients, donc le jour où la relation se termine, la question de savoir qui peut encore s'y connecter ne doit même pas se poser.
Exigez ensuite deux documents écrits en français ordinaire, sans jargon. Le premier explique comment mettre un changement en production, étape par étape. Le second explique quoi faire quand le site est tombé à vingt et une heures : qui appeler, où regarder, comment revenir à la version précédente. Tous deux doivent être rédigés pour qu'un professionnel compétent mais étranger au projet puisse les suivre sans vous téléphoner.
Le calcul rend cette exigence non négociable. Préparer un dossier de transfert correct demande 8 à 16 heures en fin de projet, alors qu'une nouvelle équipe qui arrive sans ce dossier a besoin de 40 à 120 heures rien que pour lire et comprendre le système avant de pouvoir modifier une seule ligne en sécurité. C'est le meilleur rapport qualité prix de tout le projet, et c'est pourtant la ligne que l'on supprime en premier quand le budget se tend, donc nos articles sur le transfert de projet entrent volontairement dans le détail.
Sauvegardes et sécurité sont des abonnements, pas des achats
Derrière toute politique de sauvegarde, il n'y a que deux questions, et aucune des deux n'est technique. Combien de travail pouvez-vous vous permettre de perdre, une heure, une journée ? Et combien de temps pouvez-vous rester fermé, deux heures, deux jours ? Vos réponses se traduisent presque toujours par la même chose : une sauvegarde automatique quotidienne, plus une copie conservée ailleurs que sur le serveur principal, parce qu'une sauvegarde stockée sur la machine qui brûle ne sauve rien du tout.
La règle la plus importante tient en une phrase : une sauvegarde n'est pas une sauvegarde tant que personne n'en a restauré une. Faites donc un vrai test de restauration chaque trimestre. Remettre en service une base de moins de 5 Go prend en général 10 à 40 minutes, ce qui est peu, et dans les systèmes que nous reprenons à d'autres équipes, environ une sauvegarde sur quatre se révèle incomplète ou silencieusement en échec depuis des mois. Le test compte donc davantage que la fréquence.
Il faut aussi parler du code extérieur, et l'image de l'atelier fonctionne bien : votre application assemble des pièces fabriquées par d'autres. Une application web ordinaire embarque entre 300 et 1 200 morceaux de code tiers une fois comptées les dépendances indirectes, celles que vos briques utilisent elles-mêmes sans que personne les ait choisies. Sur une année, attendez-vous à 5 à 20 qui nécessitent une mise à jour de sécurité, dont 1 à 3 qui doivent être corrigées sous 24 à 72 heures parce que la faille est publique et déjà exploitée.
Reste le facteur humain, d'où part la majorité des vraies intrusions. Activez la connexion en deux étapes pour tous les comptes administrateurs, supprimez le compte d'un salarié le jour de son départ et non trois mois plus tard, et passez en revue deux fois par an la liste de ceux qui détiennent les droits d'administration. Ce sont trois gestes gratuits qui protègent davantage que bien des outils payants, et notre équipe cybersécurité commence toujours par là, avant de proposer quoi que ce soit d'autre. Nos articles consacrés à la sauvegarde détaillent les scénarios les plus courants.
Délais de réponse : ce qu'il faut exiger et ce qu'il ne faut pas payer
Un contrat de support utile commence par classer les problèmes dans le langage du client, pas dans celui de l'informatique. Critique veut dire que le paiement ne passe plus, que la caisse est bloquée ou que le site est inaccessible. Majeur veut dire que le rapport quotidien affiche une mauvaise colonne ou que l'export ne contient pas la bonne période, bref que le travail continue mais mal. Mineur veut dire qu'un bouton est mal aligné ou qu'un libellé comporte une faute.
Les objectifs réalistes à écrire noir sur blanc découlent directement de cette échelle : une heure pour tout ce qui arrête l'argent, quatre heures ou le jour ouvré même pour un problème majeur, et deux à trois jours ouvrés pour le cosmétique. Ces délais sont tenables par une équipe normale, ce qui est précisément leur intérêt, parce qu'un prestataire qui promet quinze minutes sur tout ne tiendra ni les quinze minutes ni votre confiance.
Disons maintenant ce que la plupart des lecteurs ne devraient pas acheter. La couverture 24 heures sur 24 coûte typiquement 2,5 à 3 fois le prix d'une couverture en heures ouvrées, tout simplement parce qu'elle exige une rotation d'au moins trois personnes pour exister vraiment. Un cabinet médical qui ferme à dix-huit heures a donc raison d'acheter les heures ouvrées et d'y ajouter un numéro d'urgence pour le week-end, plutôt que de payer trois fois un service qu'il utilisera deux fois par an.
Deux détails font ensuite toute la différence entre un support qui fonctionne et un support qui existe seulement sur le papier : une personne nommée de chaque côté, et un seul canal convenu. Quand le support se disperse entre des messageries personnelles, trois numéros de téléphone et un groupe créé pour l'occasion, le résultat est toujours identique, plus personne n'est responsable et les demandes se perdent entre deux conversations.
Les petits changements qui décident si le système sera utilisé
C'est ici que se joue le retour sur investissement de tout le projet. Un logiciel qui contrarie la façon dont les équipes travaillent déjà finit discrètement abandonné, et un système que personne n'utilise coûte exactement le même hébergement qu'un système que tout le monde adore. Personne ne vous annoncera cet abandon, vous le constaterez six mois plus tard en voyant réapparaître le vieux tableur sur le bureau de la comptabilité.
La première année a une forme assez prévisible. Attendez-vous à 30 à 60 demandes de modification, dont 10 à 15 seulement changent réellement le niveau d'utilisation du système. Un budget de changement trimestriel de 10 à 20 heures couvre donc l'essentiel de ce qui compte, à condition de le dépenser sur les bonnes demandes, ce qui suppose d'écouter les personnes qui saisissent et pas uniquement celles qui décident.
Mesurez trois choses simples, exprimées dans des unités que vous comprenez déjà. Combien de collaborateurs se connectent chaque semaine, combien d'enregistrements sont créés, et combien de temps prend aujourd'hui une tâche courante par rapport à l'ancienne méthode. Si la saisie d'une commande passe de quatre minutes à quatre-vingt-dix secondes, vous avez votre réponse, et vous avez surtout un argument chiffré pour la prochaine décision d'investissement.
Prévoyez enfin une session de rappel de formation en semaine six et un guide de deux pages pour les nouveaux arrivants, car la plupart des tickets du deuxième mois ne sont pas des anomalies, ce sont des personnes à qui l'on a montré une fois et qui ont oublié. Nos études de cas présentent plusieurs systèmes dont les vrais progrès sont arrivés dans les mois qui ont suivi le lancement, sans la moindre fonctionnalité nouvelle, simplement parce que les équipes ont été reformées et que quelques écrans ont été simplifiés.
Quand l'option la moins chère est la bonne
Cette section nous coûte des ventes, et c'est justement pour cela qu'elle mérite d'être écrite. Pour un outil interne stable utilisé par cinq personnes, un forfait léger de maintien en service, aux alentours de 3 600 USD par an, est le bon achat, et tout ce qui dépasse relève du gaspillage. Vous payez la surveillance, les sauvegardes, les correctifs de sécurité et une poignée d'heures, un point c'est tout.
Il est souvent judicieux, ensuite, de remplacer une partie de votre système sur mesure par un produit du commerce quand celui-ci fait mieux le travail. La comptabilité et l'emailing en sont les meilleurs exemples, car des dizaines d'entreprises y consacrent des équipes entières et vous n'irez pas plus vite qu'elles. Le sur mesure conserve ainsi son vrai périmètre, ce qui vous est propre, et il reste petit, compréhensible et bon marché à entretenir.
À l'inverse, il faut savoir dépenser davantage. Tout ce qui porte du chiffre d'affaires, tout ce qui contient des données réglementées comme des dossiers patients ou des informations de paiement, et tout ce que vos clients voient directement mérite une couverture sérieuse, parce que le coût d'une mauvaise journée à cet endroit dépasse largement une année d'entretien. Une boutique fermée un samedi perd plus que le contrat annuel qu'elle n'a pas signé.
Méfiez-vous enfin du réflexe coûteux : quand un système paraît vieilli, une amélioration de 20 à 40 heures fait presque toujours mieux qu'une reconstruction. La refonte complète ne devrait revenir sur la table que le jour où le coût de fonctionnement de l'ancien système dépasse celui d'un système neuf, ce qui arrive rarement avant sept ou huit ans. C'est une conversation que nous avons régulièrement chez Linkysoft, et il nous arrive plus souvent qu'on ne l'imagine de conseiller la plus petite des deux options.
Vos douze premiers mois, et ce qu'il faut mettre au contrat
Voici un rythme simple, que vous pouvez recopier tel quel dans votre planning.
- Semaines une à quatre : couverture intensive, avec quelqu'un de disponible chaque jour.
- Mois deux : rappel de formation et premier lot de corrections regroupées.
- Mois trois : premier vrai test de restauration et premières petites améliorations.
- Mois six : revue des morceaux de code extérieurs et de la vitesse, car c'est le moment où la base a suffisamment grossi pour révéler les lenteurs.
- Mois neuf : conversation sur la feuille de route de l'année suivante.
- Mois douze : renouvellement, plus vérification des versions du moteur et des systèmes d'exploitation visés.
Cinq clauses méritent que vous insistiez, même si le reste du contrat vous convient parfaitement.
- Un interlocuteur nommé de chaque côté, avec son remplaçant.
- Des délais de réponse écrits, par niveau de gravité.
- Un rapport mensuel court disant ce qui a été fait, y compris et surtout les mois calmes.
- Une règle claire indiquant si les heures non consommées se reportent ou non.
- Une clause de sortie qui inclut un transfert complet du système et de tous les comptes.
Le message à retenir tient en une phrase : la question n'a jamais été de savoir si votre système aura besoin d'entretien, mais uniquement de savoir qui en porte la responsabilité et quelle somme vous avez décidé d'y consacrer. Un budget assumé, même modeste, vaut infiniment mieux qu'un budget inexistant suivi d'une facture de sauvetage.
Si vous souhaitez poser ces chiffres sur votre propre projet, nous en discuterons volontiers et sans engagement, y compris si la conclusion est que vous avez besoin de moins que ce que vous imaginiez. Vous pouvez nous contacter quand vous le voulez, ou parcourir nos autres articles consacrés à la maintenance applicative.
