Documentation technique RS&DE : Concilier réalité et hypothèses

Lors d’une vérification technique, une preuve suffisante peut faire toute la différence entre le succès et l’échec d’une réclamation.

Les conseillers en recherche et technologie (CRT) de l ’ARC s’attendent à ce que vous gériez vos projets de RS&DE en parallèle à vos projets clients.  En conséquence, l’exigence est de tenir des registres contemporains, datés, signés et spécifiques aux travaux RS&DE effectués.

En pratique, bien peu de responsables des travaux de développement vont plus loin que documenter les activités menant à la livraison d’une solution technologique chez leur client. Lors d’une vérification technique, certains CRT utilisent la mention répétée du nom de clients dans les documents mis en preuve pour considérer qu’il ne s’agit pas de preuves de l’expérimentation RS&DE mais plutôt de la livraison normale d’un projet client.

Comment concilier la réalité des travaux de développement et les exigences de l’ARC ? Distinguons ici deux types de justification : le projet de développement, souvent réalisé en partie chez un client, et le projet expérimental de RS&DE, surtout réalisé dans la tête des concepteurs de la technologie.

1-   Justification des travaux de développement

À l’annexe 2 de la T4088, l’ARC identifie dans un tableau des « Exemples de preuves à l’appui des travaux de RS&DE » :

• Documents de planification de projet
• Registres d’attribution des ressources au projet, feuilles de temps
• Plans d’expériences
• Documents de conceptions, conception assistée par ordinateur (CAO) et dessins techniques
• Registres du projet, carnets de laboratoire
• Conception, architecture du système et code source (développement de logiciels)
• Registres d’essais
• Rapports de progrès de projet
• Comptes rendus de rencontres de projet
• Protocoles d’essais, données d’essais, résultats d’essais
• Analyses de résultats d’essais, conclusions
• Rapport final de projet ou publications professionnelles
• Photographies et vidéos
• Prototypes, échantillons
• Matériaux détruits, enregistrements d’élimination de matériaux
• Contrats et factures

Tous ces documents sont typiques d’un projet de développement conventionnel. Le problème c’est qu’ils sont normalement produits dans le cadre d’un projet client. Aucun ne relie ces travaux aux objectifs, incertitudes et avancements technologiques réclamés dans le formulaire T661. Alors, que manque-t-il pour prouver les travaux expérimentaux ?

2-   Justification des travaux expérimentaux : documenter les hypothèses RS&DE 

Bizarrement aucun des documents listés plus haut et dans le tableau 1 de l’annexe 2 du guide T4088, n’est relié à la colonne : « Travaux effectués : expérimentation, analyse, travaux de soutien, progrès (avancements) »qui correspond à la ligne 244 du formulaire T-661. Pourquoi ?

La réponse c’est le registre des hypothèses qui est défini dans la description de la cinquième question pour déterminer s’il y a de la RS&DE:

« [L’ARC] s’attend à ce que les travaux soient consignés de façon à indiquer clairement la raison d’être de leurs principaux éléments et préciser comment ils s’inscrivent dans l’ensemble du projet. Les indicateurs ou les mesures qui serviront à déterminer si les objectifs du projet sont atteints devraient être identifiés et consignés dès le début des travaux. (politique 2.1.5)

Donc, l’ARC s’attend à ce que nous ayons à la fois de l’information de suivi de projet de développement et de l’information de suivi du processus expérimental réclamé.

Deux remarques importantes subsistent malgré cette définition :

2.1 Il faut documenter l’acquisition de connaissance

Le registre des hypothèses est le seul endroit où l’on peut lier l’acquisition de connaissance aux activités, aux incertitudes et aux avancements technologiques. C’est donc un document clé pour supporter votre réclamation technique.

Attention, la qualité prévaut sur la quantité. Démontrons ici l’acquisition de connaissances plutôt que la génération d’une masse d’informations plus ou moins pertinentes.

2.2 Hypothèse = choix

Personne n’utilise le mot hypothèse dans les échanges quotidiens entre membres de l’équipe de développement. L’ARC exige pourtant « un registre des hypothèses vérifiées et des résultats conservés au cours des travaux ».

D’abord, dans un projet réel de développement technologique, l’émission d’hypothèses en vue de résoudre une incertitude est un exercice qui se passe entre les deux oreilles de ceux qui conduisent les travaux. Il faut donc expliciter, faire verbaliser et écrire les hypothèses soulevées, même si elles ont été rejetées avant même de les tester formellement.

De plus, le mot « hypothèse » est certainement loin de la réalité des ingénieurs et concepteurs de solutions. Il serait plus clair d’utiliser le terme « option » ou « choix ».

Au fond, ce que l’ARC recherche c’est un registre des incertitudes rencontrées, des choix considérés, des essais réalisés, des résultats obtenus, ainsi que de la connaissance que nous en avons tirée.

3-   Conclusion

En guise de conclusion, rappelons que pour l’ARC, nous réclamons un processus expérimental systématique, où la progression des travaux se fait par une analyse des résultats étape par étape. Dans ce contexte, pour exploiter les résultats des essais, il faut enregistrer, écrire, noter, les travaux d’expérimentation et d’analyse qui nous mèneront un jour à résoudre les incertitudes technologiques et à mieux comprendre les relations scientifiques ou technologiques (aussi appelé avancement scientifique ou technologique).

Nous sommes honorés de votre visite sur notre blogue. R&D Action vous en remercie.

À droite de cette page l’index contient plusieurs autres catégories de solutions pratiques et applicables qui vous sont aussi destinées.

Vous avez aimé votre lecture ? Dites-le-nous. Partagez-la. Que devrait-on y ajouter ? Quels sujets vous intéressent ?

Vous n’avez pas aimé cette lecture ? Dites-le-nous. Qu’avez-vous moins apprécié dans ce texte ? Comment peut-on mieux répondre à vos besoins ?