Le 28 juillet, j’ai fait deux modifications qui n’avaient rien à voir en apparence.
D’un côté, j’ai ajouté des logs quand un email ne part pas. De l’autre, j’ai déplacé le formulaire d’abonnement à la newsletter en bas de la page du blog, avec un simple lien en haut.
Un changement concernait le serveur. L’autre, la mise en page. Pourtant, ils venaient de la même question : qu’est-ce que mon logiciel oblige encore à deviner ?
Cette question ne vient pas du portfolio. Je l’ai récupérée dans deux autres projets.
## PIL OS m’a appris qu’un envoi ne prouve rien
PIL OS est un réseau construit dans Minecraft avec Lua et CC:Tweaked. Un serveur central garde l’état. Les téléphones, les bornes ATM et la console lui envoient des demandes par modem sans fil.
Dans ce contexte, appeler une fonction d’envoi ne signifie pas que le destinataire a traité le message. La documentation des modems de CC:Tweaked sépare clairement la transmission et la réception : un ordinateur transmet sur un canal, puis un autre doit écouter l’événement correspondant. Même l’API rednet, qui ajoute une abstraction au-dessus des modems, précise qu’un envoi réussi ne garantit pas la réception.
Avec PIL OS, cette différence n’était pas théorique. Les machines pouvaient décrocher. Le serveur pouvait ne pas répondre. Un message pouvait arriver sous une forme que le client n’attendait pas. J’ai donc commencé à voir une API comme un échange incertain plutôt que comme un simple appel de fonction distant.
Ce réflexe est revenu dans le portfolio avec les emails.
Quand le SMTP n’était pas configuré, mes fonctions d’envoi ne faisaient rien. Aucun message envoyé, aucune erreur visible. Depuis l’extérieur, deux situations différentes produisaient exactement le même résultat :
- la fonction n’avait pas pu envoyer l’email ;
- le serveur SMTP avait refusé ou perdu le message.
Pour moi, c’était juste : « je n’ai rien reçu ».
J’ai ajouté des logs pour séparer ces états. Ce n’est pas une nouvelle architecture. C’est simplement le minimum pour que l’appelant, ou moi devant les logs du VPS, n’ait pas à deviner ce qui s’est passé.
La documentation Next.js conseille aussi de traiter les erreurs attendues comme des résultats explicites, plutôt que de laisser chaque échec devenir une exception indistincte. PIL OS m’avait déjà appris la raison pratique : une API ne décrit pas seulement ce qui se passe quand tout fonctionne. Elle doit aussi rendre lisible l’absence de réponse.
## Le dashboard m’a appris que la friction se multiplie
Mon dashboard remplace le nouvel onglet de mon navigateur. Je l’ouvre des dizaines de fois par jour. À cette fréquence, une petite gêne cesse vite d’être petite.
Un widget lent finit par disparaître. Une information mal placée devient une recherche répétée. Une action qui demande un clic inutile le redemande encore le lendemain.
C’est ce projet qui m’a fait arrêter de juger une interface uniquement pendant que je la construis. À la première utilisation, presque tout semble acceptable. La vraie mesure arrive après plusieurs dizaines de passages.
Sur la page du blog, j’avais placé le formulaire d’abonnement juste sous le bloc d’introduction. Il était visible, mais il repoussait la liste des articles. Chaque visiteur venu lire devait traverser un élément qui ne concernait que les personnes voulant s’abonner.
Je n’ai pas supprimé la newsletter. J’ai déplacé son coût.
Le formulaire vit maintenant en bas de page. En haut, un lien discret mène directement jusqu’à lui. La fonction reste accessible, mais elle ne bloque plus le chemin principal. C’est exactement le type d’arbitrage que mon dashboard m’a appris à faire : optimiser ce qui se répète, pas ce qui occupe le plus de code.
## Le même problème des deux côtés
PIL OS m’a appris à ne pas faire deviner l’état d’un échange. Le dashboard m’a appris à ne pas faire deviner le chemin utile dans une interface.
Dans un cas, le client doit savoir si sa demande a échoué. Dans l’autre, le lecteur doit trouver les articles sans contourner un formulaire. Ce ne sont pas les mêmes couches, mais le défaut est proche : le logiciel garde une information pour lui et laisse l’utilisateur reconstruire la suite.
Je vais maintenant repasser sur le panneau d’administration du portfolio avec ces deux questions : quelles opérations peuvent encore échouer sans trace, et quelles actions répétées demandent encore un détour. La prochaine modification viendra probablement de l’une de ces deux listes.