L’enseignement des tests de non-régression

Il y a un constat que seuls celles et ceux qui ont vécu l’informatique des années 2000 peuvent vraiment faire. Les mises à jour de programme c’est quand même bien plus fluide qu’avant.

Avant, c’est vrai que, lorsque tu touchais à un truc, ça branlait dans le manche à un autre endroit. Heureusement, tout cela s’est nettement amélioré. Cela vient évidemment de très nombreuses choses qui ont évoluées, les frameworks de développement ou les outils comme « git » qui gèrent le versioning, par exemple.

Dans cette perspective, une notion qu’on utilise dans les projets informatiques c’est ce qu’on appelle les TNR ou les tests de non-régression. Or, c’est une notion dont on pourrait bien s’inspirer dans de nombreux autres domaines.

Comme en RH ou en management par exemple ? Alors, l’enseignement des tests de non-régression, c’est quoi l’histoire ?

En informatique, les tests de non-régression, c’est d’une simplicité déconcertante à comprendre. Un peu moins à mettre en œuvre, mais c’est un autre sujet.

Le principe c’est de faire des tests qui garantissent qu’une correction, ou une évolution, ne vient pas briser quelque chose qui marchait bien avant. Genre, tu résous un problème mais tu as cassé ce qui fonctionnait bien.

D’où l’expression « non-régression » pour éviter le syndrome d’un pas en avant, deux pas en arrière. Les initiés appellent cela les TNR et cela correspond à des batteries de tests généralement automatisés pour s’assurer que tout fonctionne bien comme avant.

On les fait d’ailleurs à plusieurs stades d’un projet informatique. Quand on a fini de coder une fonctionnalité spécifique pour s’assurer qu’elle n’a pas de conséquence négative sur des fonctionnalités précédentes, notamment celles qui sont fondamentales.

Mais aussi à chaque livraison d’ensemble de fonctionnalités, à la fin d’un projet ou de sous-étape de projet ou à la livraison d’un patch correctif. Bref, la philosophie est assez simple à se figurer et se résume à s’assurer que ce que l’on fait n’abîme pas ce que l’on a déjà fait.

On cherche à éviter de déshabiller Pierre pour habiller Nicolas. Or, un principe de ce type entérine une idée importante : une chose prise séparément a aussi des conséquences potentielles sur d’autres choses.

Dit autrement, c’est la résultante d’une compréhension de la complexité et de ce qui unit les parties d’un tout. Or, c’est le cas pour de très nombreux domaines, à commencer par celui de l’humain, de son management ou de sa gestion.

Tu mets en place une nouvelle prime pour inciter à je-ne-sais-quoi par exemple. As-tu réfléchi aux conséquences au-delà de ce je-ne-sais-quoi ? On connaît les théories autour des incitations désincitatives de Bruno Frey, professeur à l’Université de Zurich ! Tout est dit.

Un ouvrage de 2009 de Maya Beauvallet intitulé « Les Stratégies absurdes: Comment faire pire en croyant faire mieux » (Beauvallet, 2009) collectionnait les choses de ce genre.

Il y a de très nombreux sujets en management des ressources humaines qui pourraient illustrer ce besoin de tests de non-régression, du moins sur le plan conceptuel.

Tu te lances, par exemple, dans une lourde opération de définition des compétences par métier, en t’appuyant sur une logique de filière métier, parce que tu souhaites favoriser la mobilité et donner de la visibilité aux collaborateurs quant à leur carrière.

L’intention est bonne et louable. Mais face à l’ampleur de la tâche tu te concentres pour chacun des postes aux compétences métiers clés qu’il demande. Ton référentiel de compétences est donc en quelque sorte siloté par filière métier.

Ce qui va naturellement nuire à la mobilité inter métier ou du moins à leur identification et à leur formalisation par l’intermédiaire de tes référentiels de compétences. Or, les passerelles entre métiers ne fonctionnaient pas si mal que cela.

Mais à l’intuition, au pif. Sauf qu’en introduisant une démarche plus « normalisante » tu risques bien de mettre tout cela à mal.

La principale difficulté c’est en effet de comprendre que les choses sont reliées entre elles et, sans entrer dans l’exagération de la théorie du papillon, il n’est pas rare qu’en agissant d’un côté cela a des impacts d’un autre.

La RSE, dès lors qu’on l’appréhende dans toute sa complexité, est un bon exemple. Les boucles de rétroaction peuvent y être nombreuses, or c’est justement ces fameuses boucles qui exigent une plus grande attention aux conséquences globales d’une décision particulière.

Alors, si on ne sait pas bien comment on pourrait industrialiser des tests de non-régression dans des domaines de ce type, du moins en première lecture, on peut au moins se dire deux choses.

La première, c’est d’en retenir le principe et d’en faire un guide dans nos décisions. Nous obliger à nous poser pour mieux réfléchir aux conséquences globales.

La seconde, c’est de formaliser un peu les liens entre les choses pour mieux développer cette vision globale.

Le principal enseignement des tests de non-régression c’est bien celui-ci en effet. Celui d’une exigence et d’une rigueur intellectuelle, caractéristique d’un certain sens des responsabilités, qui consiste à apprécier les conséquences de ce que l’on fait au-delà de son périmètre immédiat.

En résumé, les tests de non-régression en informatique constituent une disposition d’esprit qui consiste à s’assurer que ce que l’on fait n’a pas de conséquences néfastes sur un périmètre plus vaste, dans le temps et l’espace. Une exigence intellectuelle dont la fonction RH devrait s’emparer face à la complexité des sujets qu’elle traite.

J’ai bon chef ?

Oui tu as bon mais on ne va pas en faire toute une histoire.