Le Principe de robustesse

Dans le domaine des pro­to­coles de com­mu­ni­ca­tion, le Principe de robus­tesse veut qu’un nœud d’un réseau (par exemple un ser­veur sur Internet) soit tolé­rant quand il décide d’accepter ou non un mes­sage plus ou moins bien for­mé, et qu’il soit plus rigou­reux sur la qua­li­té des mes­sages qu’il envoie. Le prin­cipe voit son ori­gine dans les débats autour de l’importance qu’il faut don­ner à une norme de com­mu­ni­ca­tion : la stra­té­gie opti­male pour la robus­tesse du réseau, ce serait de suivre la norme de près en out­put mais beau­coup moins en input.

Par la suite (RFC 1122, § 1.2.2), il été a inter­pré­té de manière plus large comme un prin­cipe de pré­voyance :

Software should be writ­ten to deal with eve­ry concei­vable error.

C’est-à-dire : ren­dez votre pro­gramme robuste en le conce­vant de telle sorte à qu’il fonc­tionne avec les plus inputs les plus variés.

La rhé­to­rique dis­pose d’un couple de règles très simi­laire : les prin­cipes d’honnêteté intel­lec­tuelle et de cha­ri­té. Le pre­mier revient à dire qu’il faut faci­li­ter le tra­vail de com­pré­hen­sion de l’interlocuteur, le second qu’il faut inter­pré­ter ses pro­pos de la manière la plus avan­ta­geuse pos­sible. (Note : c’est une vision à mini­ma. L’honnêteté intel­lec­tuelle ne se limite pas à un sou­ci de clar­té. De manière plus dras­tique, ces prin­cipes rap­pellent qu’il faut veiller à avoir un lan­gage et des valeurs de dis­cus­sion com­muns.)

Il y a un troi­sième domaine où ce prin­cipe peut s’appliquer : les IHM. La mani­pu­la­tion d’un pro­gramme peut être vue comme un dia­logue : l’utilisateur demande quelque chose et le sys­tème répond qu’il a bien effec­tué (ou non) la tâche, tout ceci via le lan­guage de l’interface. La méta­phore a notam­ment été déve­lop­pée par Hutchins dès 1987 (article en lien ici – PDF pour­rave mais réflexion pas­sion­nante), qui en note aus­si les limites : elle sup­pose qu’il y a une média­tion de type sym­bo­lique entre l’homme et la machine, avec toute la com­plexi­té et l’ambiguïté que cela implique.

Pourtant, cette méta­phore de la conver­sion s’applique encore à bien des cas, par exemple la com­plé­tion d’un for­mu­laire : j’entre une date et le pro­gramme me répond si elle a bien été com­prise. Une bonne inter­face est tolé­rante dans les for­mats pos­sibles qu’elle admet en entrée et rigou­reuse (cohé­rente) à chaque fois qu’elle doit affi­cher une date en sor­tie.

Le prin­cipe de robus­tesse sur Wikipedia