Quand on teste un outil, on vérifie qu'il fait ce qu'on attend de lui. On vérifie beaucoup plus rarement qu'il refuse ce qu'il doit refuser. C'est pourtant de ce côté que se trouvent les défauts les plus coûteux, parce qu'ils ne se révèlent pas à l'usage normal.
Le test qu’on oublie
Construire un outil, c’est ajouter des fonctions : créer une facture, ouvrir un dossier client, envoyer un document. À chaque fonction ajoutée, on vérifie naturellement qu’elle marche. Le réflexe est sain, mais il est incomplet. Car un outil ne se définit pas seulement par ce qu’il permet ; il se définit aussi par ce qu’il interdit.
Un utilisateur ne doit pas voir les données d’un autre. Une facture déjà émise ne doit plus pouvoir être modifiée. Une formule d’abonnement ne doit pas donner accès à ce qu’elle n’inclut pas. Aucun de ces refus ne se constate en utilisant l’outil normalement : tant que personne n’essaie de franchir la limite, on ignore qu’elle existe. On le découvre le jour où quelqu’un la franchit, par erreur ou volontairement, et ce jour-là, il est déjà tard.
L’exemple d’un logiciel de gestion
Kheris Workspace est un logiciel de gestion, un ERP conçu en septembre 2026 pour des petites entreprises : clients, factures, encaissements, contrats, trésorerie. Plusieurs entreprises l’utilisent en même temps, chacune avec son accès. C’est exactement le type d’outil où un refus manquant peut faire des dégâts : une entreprise qui verrait les données d’une autre, ce n’est pas un défaut d’affichage, c’est une faute grave.
Son cahier des charges a donc posé une règle dès le départ : les limites existent dès les premières lignes de code, et pas à la fin. La raison est simple. Si tout est autorisé pendant la construction, on ne teste jamais le cas refusé ; on découvre les portes qui ne ferment pas au moment de les fermer, quand tout le reste repose déjà dessus. La même logique a guidé d’autres choix : chaque entreprise est isolée des autres au niveau de la base de données elle-même, et pas seulement à l’écran ; une facture émise ne se supprime jamais, elle s’annule par un avoir ; et une suppression « douce », qui se contente de cacher, ne suffit pas quand un utilisateur demande à être réellement effacé.
Promettre seulement ce qu’on fait respecter
Une note affiche des différences : telle offre permet ceci, telle autre ne le permet pas. Chacune de ces différences est une promesse faite au client. Si rien, dans l’outil, ne la fait respecter, la différence n’existe que sur la plaquette.
D’où une règle que je m’applique désormais : chaque différence doit correspondre à une capacité réellement verrouillée. Une option grisée dans l’interface ne suffit pas, si elle reste accessible à qui sait contourner l’écran ; le refus doit être inscrit là où sont les données. J’avais appliqué le même principe au système de pilotage construit auparavant pour une équipe de sept personnes, où chaque rôle (saisie, pilotage, direction) ne voit que ce qui le concerne. Le vérifier ne consiste pas à regarder l’écran du responsable, mais à se connecter avec le rôle le plus restreint et à chercher ce qu’il ne devrait pas trouver.
Un outil se juge à ce qu’il permet. Il se protège par ce qu’il refuse.