garde-fous

En profondeur

Les garde-fous se placent à trois endroits, et confondre ces endroits fait perdre l’essentiel du bénéfice. En amont, on limite ce qui entre : quelles sources sont lisibles, quelles demandes sont recevables, quelles données ne doivent jamais rejoindre le contexte. Au moment d’agir, on limite ce que le système peut déclencher : outils autorisés, droits réduits au strict nécessaire, plafonds, confirmation humaine pour tout ce qui est irréversible. En aval, on vérifie ce qui sort avant qu’il atteigne une personne ou un autre logiciel : forme attendue, présence des sources, absence d’informations qui ne devaient pas circuler.

Le principe qui les gouverne tient en une phrase : un garde-fou suppose que le modèle a échoué. Il ne s’agit pas de le rendre plus sage, mais de faire en sorte qu’une sortie fausse, détournée ou absurde ne produise pas de dégât durable. C’est pourquoi un garde-fou efficace vit hors du texte : une vérification inscrite dans le harnais s’applique quoi qu’il arrive, tandis qu’une consigne insérée dans le contexte partage le sort de tout le reste et peut être contredite par un document lu au passage. La bonne question n’est donc jamais de savoir si le modèle obéira, mais ce qui se passe le jour où il n’obéit pas.

Le premier piège est l’excès : des limites trop serrées produisent un système qui refuse tout, que les équipes contournent en allant travailler ailleurs, hors de toute surveillance. Le deuxième est le garde-fou décoratif, cette demande de confirmation à laquelle plus personne ne prête attention au bout de la centième fois : une validation qu’on ne peut pas refuser n’en est pas une. Le troisième est de croire qu’ils s’écrivent une fois pour toutes, alors qu’ils se choisissent en fonction du dégât redouté, se testent comme le reste du système et se revoient chaque fois que le périmètre d’action s’élargit. Le dernier est de les confondre avec la conformité réglementaire, qui impose des obligations de résultat sans dire comment brider un outil précis.