Construire des logiciels défensifs

Pourquoi faire ce qu’il faut peut-il ressembler à ne rien faire ?

macOS possède une fonction appelée Secure Input (saisie sécurisée) qui empêche d’autres processus d’intercepter les saisies clavier sensibles. C’est important pour une app comme Comoji, qui doit reconnaître ce que vous tapez pour proposer l’autocomplétion. Un utilitaire d’emojis n’a rien à faire à vous regarder saisir un mot de passe, donc Comoji se met délibérément en retrait tant que Secure Input est actif.

Dans ce cas précis, Chrome apparaissait comme le processus qui détenait Secure Input, alors que je n’étais plus en train de saisir un mot de passe. J’ai tué Chrome en pensant que cela réglerait le problème. Au lieu de cela, Secure Input est resté actif, et il était désormais associé au processus de connexion d’Apple. Quoi qu’il se soit passé de travers après le redémarrage, fermer le navigateur n’avait pas suffi à le résoudre.

C’est une catégorie de problème qu’Apple a elle-même documentée. Une application qui laisse Secure Input activé alors qu’elle n’en a plus besoin peut interférer avec d’autres applications qui dépendent des événements clavier, même après que l’application fautive est passée en arrière-plan. Le mécanisme de sécurité continue de faire son travail, mais les logiciels ailleurs sur la machine en subissent les conséquences.

C’était la situation dans laquelle se trouvait Comoji. Il refusait à juste titre de fonctionner tant que le système indiquait que la saisie clavier devait être protégée. Mais rien de tout cela n’était visible pour moi. J’avais écrit l’app, et même moi, au début, je n’ai vu que le fait qu’elle avait cessé de fonctionner.

Un utilisateur ne devrait pas avoir à enquêter sur l’état du système d’exploitation pour comprendre pourquoi ses raccourcis d’emoji ne font soudainement plus rien.

Pourquoi « ce n’est pas mon bug » n’est-il pas une réponse complète ?

La tentation d’arrêter d’enquêter dès que l’on a établi qu’un problème vient d’en dehors de son code est compréhensible. Chrome détenait Secure Input. Puis le processus de connexion d’Apple était impliqué. Comoji se comportait exactement comme prévu. Affaire classée, non ?

Pas vraiment. Cela explique qui a causé le problème, mais cela n’aide pas la personne qui essaie d’utiliser mon app. Elle ne regarde pas quel processus appartient à qui et ne décide pas quelle entreprise mérite un rapport de bug. Elle regarde Comoji et se demande pourquoi il ne fonctionne pas.

Le problème de saisie sous-jacent se situait en dehors de Comoji. L’absence d’explication, elle, était quelque chose que je pouvais corriger.

C’est là que le développement logiciel défensif va au-delà de la vérification des arguments invalides et de la capture des exceptions. Il faut aussi réfléchir à l’apparence de votre application quand l’environnement qui l’entoure cesse de se comporter correctement. L’utilisateur peut-il distinguer une pause délibérée d’un plantage ? Sait-il ce qui empêche l’app de fonctionner ? Lui avez-vous donné un endroit utile où aller ensuite ?

Avoir techniquement raison n’est pas d’un grand réconfort quand votre produit a l’air cassé.

Qu’ai-je changé ? Un petit cadenas plutôt qu’un mystère

J’ai ajouté un petit indicateur de cadenas à l’icône de Comoji dans la barre des menus chaque fois que Secure Input est actif. Il y a désormais une raison visible à l’absence d’autocomplétion : Comoji est en pause parce que la saisie clavier est protégée. L’app ne présente plus en silence une fonction indisponible comme si elle était censée fonctionner.

J’ai aussi relié le menu de la barre à un article d’aide qui explique ce qu’est Secure Input et pourquoi Comoji le respecte. Quelqu’un qui se retrouve bloqué peut atteindre cette explication depuis l’app elle-même, au lieu de devoir deviner les bons termes de recherche ou me contacter pour découvrir que cette fonction du système existe.

L’important, c’est ce que je n’ai pas essayé de résoudre. La réponse n’était pas de contourner la protection des mots de passe juste pour que l’autocomplétion des emojis fonctionne. Que Secure Input soit actif n’est pas, en soi, une erreur. Il existe pour une bonne raison, et Apple prévient explicitement qu’activer la saisie sécurisée au clavier peut affecter d’autres apps qui ont besoin de ces frappes.

Le cadenas communique donc un état, pas une crise. Lors d’une saisie normale de mot de passe, il explique pourquoi Comoji est temporairement indisponible. Quand cet état persiste de manière inattendue, il donne à l’utilisateur un point de départ pour comprendre ce qui s’est passé.

Je n’ai pas rendu Chrome ou macOS incapables de se bloquer. J’ai rendu leur blocage moins déroutant pour quelqu’un qui utilise Comoji, sans affaiblir la protection que Comoji était censé respecter.

Pourquoi les grandes entreprises restent-elles des dépendances externes ?

Il y a quelque chose d’agaçant à blinder un minuscule utilitaire contre des problèmes impliquant le navigateur de Google et le système d’exploitation d’Apple. Ce ne sont pas des composants obscurs que j’aurais traînés dans le projet sans réfléchir. Ce sont les produits de deux énormes entreprises technologiques, et leur comportement a quand même réussi à faire passer ma petite app pour défectueuse.

Mais leur taille ne change rien à la décision d’ingénierie. Je ne peux pas construire Comoji en partant du principe que tout ce que produit une entreprise plus grosse que la mienne se comportera toujours correctement. Je ne peux pas non plus dire à un utilisateur frustré que le problème appartient à une entreprise suffisamment impressionnante et considérer mon travail comme terminé.

Je ne sais pas à quelle fréquence cette séquence précise se produit. Elle est peut-être inhabituelle. Mais je l’ai vécue, et le résultat a mis en lumière une distinction utile : Comoji gérait déjà la condition de sécurité de manière sûre ; il ne gérait pas encore bien la confusion qui en résultait.

Cela ne veut pas dire que chaque défaillance hypothétique mérite un nouveau réglage, une boîte de dialogue d’avertissement ou un sous-système de récupération. Dans ce cas, la réponse était petite et directement liée au problème. Une icône de cadenas a rendu la condition visible. Un article d’aide l’a rendue compréhensible. Ni l’un ni l’autre n’exigeait de prétendre que je pouvais réparer une autre application depuis l’intérieur de la mienne.

Pour moi, c’est une part importante de la construction d’un logiciel défensif. Votre responsabilité ne s’arrête pas à vous assurer que votre code fonctionne quand tout ce qui l’entoure fonctionne. Vous devez aussi décider de ce qui se passe quand il ne peut pas faire son travail, y compris quand la raison est l’erreur de quelqu’un d’autre.

Parfois, le bon comportement consiste à s’arrêter. Un bon logiciel devrait pouvoir vous dire pourquoi.