Concevoir pour une connexion qui tombe
Une application de gestion utilisée à Niamey perd le réseau. Pas une fois par trimestre : plusieurs fois par jour, quelques secondes ou quelques minutes, et l'électricité suit le même rythme.
Un logiciel écrit ailleurs traite cela comme un cas d'erreur — un écran rouge, un message d'excuse. Ici c'est un cas courant, et un cas courant se conçoit. La question n'est donc pas « comment éviter la coupure », sur laquelle vous ne pouvez rien, mais « qu'est-ce que l'utilisateur devra retaper », sur laquelle vous pouvez tout.
Le formulaire d'une heure
L'inventaire annuel se saisit sur un écran, trois cents références, une heure de travail. Le réseau tombe à la validation. Tout est perdu.
Ce n'est pas un défaut de gestion d'erreur, c'est un défaut de découpage : l'écran n'aurait jamais dû exiger une heure avant d'enregistrer quoi que ce soit. Un inventaire s'enregistre par zone, une commande par ligne, un devis à chaque section. Chaque étape est validée, courte, et reprise là où elle s'est arrêtée.
La règle que nous nous donnons : aucun écran ne doit pouvoir faire perdre plus de deux minutes de saisie. Si un écran peut en faire perdre trente, il est à découper, quelle que soit la qualité du réseau le jour de la démonstration.
Le double clic qui crée deux factures
L'utilisateur valide. Rien ne se passe. Il revalide. La première requête était partie, elle a seulement mis du temps à répondre : deux factures, deux mouvements de stock, deux numéros consommés.
La parade est connue et coûte peu : un jeton engendré avec le formulaire, transmis à la validation, refusé la seconde fois. La deuxième soumission ne produit rien et renvoie le résultat de la première.
Sans ce jeton, la seule protection est de désactiver le bouton en JavaScript — c'est-à-dire de faire dépendre l'intégrité de vos écritures comptables du bon fonctionnement d'un script, sur un téléphone d'entrée de gamme, pendant une coupure réseau.
« Lent » et « en panne » ne se ressemblent pas
Le pire état d'une application n'est pas l'erreur : c'est l'attente sans terme. Un indicateur qui tourne indéfiniment ne dit rien, et l'utilisateur finit par recharger — ce qui nous ramène au paragraphe précédent.
Un délai maximal, un message clair, et une reprise qui ne risque pas de dupliquer valent mieux qu'une attente polie. « La connexion a été perdue, votre saisie est conservée, réessayez » est une phrase qu'on peut écrire seulement si les deux points précédents ont été traités.
Pourquoi le hors-ligne complet est rarement la bonne réponse
C'est la demande naturelle : « faites que ça marche sans réseau ». Pour une application de gestion, c'est presque toujours une mauvaise idée, et il faut le dire avant de la mettre en œuvre.
Deux vendeurs hors ligne attribuent la dernière pièce du stock. Deux postes hors ligne prennent le même numéro de facture. À la reconnexion, il faut trancher — et ce n'est pas un problème technique, c'est une décision de gestion à laquelle il n'existe pas de bonne réponse automatique. Le logiciel choisit alors à la place du gérant, silencieusement.
Notre position par défaut : la consultation fonctionne hors ligne, la saisie reste en ligne et courte. Voir son stock, retrouver un client, rouvrir une facture : depuis le cache, sans réseau. Écrire : en ligne, par petits morceaux.
On inverse cette règle uniquement quand le travail se fait réellement là où il n'y a pas de réseau — une tournée, un chantier, un relevé de compteurs — et alors seulement pour un écran conçu pour ça, avec une file d'attente que l'utilisateur voit, dont il connaît la taille, et qui refuse d'elle-même les opérations que le hors-ligne ne sait pas arbitrer.
Et la coupure de courant
Elle frappe le serveur au milieu d'une écriture. La protection n'est pas l'onduleur, c'est la transaction : trois tables modifiées le sont ensemble ou pas du tout. Un logiciel qui écrit ses trois tables l'une après l'autre en espérant arriver au bout laisse, après une coupure, une facture sans ses lignes ou un stock déduit deux fois.
Quant aux vingt minutes que tient l'onduleur, elles servent à éteindre proprement, pas à continuer de travailler. Une équipe qui prend l'habitude de saisir pendant la coupure finit par saisir pendant la dernière minute.
La question à poser
Devant n'importe quel écran de saisie :
Si la connexion tombe maintenant, qu'est-ce que je dois retaper ?
Si la réponse dépasse deux minutes de travail, l'écran est à revoir. C'est le seul critère que nous connaissions qui se vérifie sans réseau de test et sans outillage.