Le développeur invisible

Il existe une forme de réussite informatique qui ne reçoit presque jamais d'applaudissements.

Le site s'ouvre.

Les formulaires fonctionnent.

Les utilisateurs se connectent.

Les sauvegardes se font.

Et personne n'en parle.

Puis, un matin, un service cesse de répondre.

Là, tout le monde découvre soudain qu'il y a un informaticien quelque part. 😅

Le succès qui ne se voit pas

Quand on montre une nouvelle application, on peut présenter une interface, une fonctionnalité, une animation.

C'est concret. C'est visible.

La maintenance, elle, ressemble souvent à une absence d'événement.

Un certificat renouvelé avant d'expirer. Une sauvegarde testée. Une alerte repérée à temps. Une dépendance mise à jour avant qu'elle ne devienne un problème.

Ces tâches ont une valeur immense.

Mais on les remarque surtout lorsqu'elles n'ont pas été faites.

Ce qu'il y a derrière « le site marche »

Un produit en ligne ne s'arrête pas à sa mise en production.

Il dépend d'un hébergement, de noms de domaine, de bibliothèques, de services externes, de secrets, de bases de données et de personnes qui savent comment intervenir.

Prenons une plateforme qui envoie des notifications.

Si le service d'envoi échoue, l'interface peut rester parfaitement belle. Mais le client ne reçoit plus ses confirmations.

Le problème n'est pas toujours visible sur la page d'accueil.

C'est pourquoi il ne suffit pas de demander : « Est-ce que le site est accessible ? »

Il faut parfois demander : « Est-ce que le parcours essentiel fonctionne encore du début à la fin ? »

Prévenir coûte du temps

Sauvegarder les données ne suffit pas si personne n'a jamais essayé de les restaurer.

Recevoir des alertes ne suffit pas si tout le monde les ignore.

Mettre à jour une dépendance ne suffit pas si la mise à jour casse une fonction critique.

La fiabilité demande des habitudes :

• Identifier les parcours les plus importants.
• Vérifier régulièrement les sauvegardes et la restauration.
• Surveiller les erreurs, la disponibilité et les ressources.
• Tester les changements avant de les déployer.
• Documenter les procédures d'urgence.
• Garder une trace des accès et des responsabilités.

Il n'est pas nécessaire de créer une organisation gigantesque pour commencer.

Mais il faut considérer ces tâches comme du vrai travail.

Le support est aussi un métier humain

Quand quelque chose ne fonctionne pas, l'utilisateur n'a pas forcément envie d'entendre une longue explication sur les serveurs.

Il veut savoir ce qui se passe, ce qu'il doit faire et à quel moment le service peut revenir.

Une bonne réponse commence souvent par l'écoute et une information claire.

Éviter de promettre une résolution immédiate lorsqu'on ne sait pas encore d'où vient le problème fait partie du professionnalisme.

Les personnes qui travaillent au support le savent bien : une panne technique devient rapidement un problème de communication.

Faire payer l'invisible

La maintenance est parfois mal comprise dans les devis.

Pourquoi payer chaque mois si rien ne change visuellement ?

Justement parce que le but est souvent que rien ne se dégrade.

Il faut expliquer ce que couvre un contrat : mises à jour, supervision, assistance, sauvegardes, sécurité, délais de réponse et ce qu'il ne couvre pas.

Sinon, les attentes deviennent impossibles à tenir.

J'aborde aussi les coûts de maintenance dans Le rêve du petit SaaS.

La prochaine fois qu'une application marche

Je ne demanderai pas qu'on applaudisse le développeur à chaque chargement de page.

Ce serait fatigant pour tout le monde. 😂

Mais j'aimerais qu'on se souvienne qu'un système fiable n'est pas simplement un système bien conçu le jour de son lancement.

C'est un système dont quelqu'un prend soin après le lancement.

Et ce travail-là mérite d'être visible, au moins dans la manière dont on organise, reconnaît et finance les projets numériques.