Annexe IV · 11 min de lecture
Annexe IV : pourquoi le Technical File devient un actif critique.
Le Technical File ne devrait pas être un PDF déposé une fois. C'est un actif vivant, versionné, lié au système.
Un livrable, ou un actif ?
Beaucoup de Technical Files vivent comme des livrables figés. Produits une fois pour répondre à une exigence, ils dérivent ensuite par rapport à la réalité du système. Cette dérive est précisément ce que l'Annexe IV ne tolère pas dans la durée.
La mémoire structurée du système
L'Annexe IV demande une documentation technique cohérente : description, finalité, choix techniques, gouvernance des données, gestion du risque, supervision humaine, monitoring. Pris ensemble, ces éléments forment la mémoire structurée du système.
Le piège du « one-shot »
Un Technical File rédigé une fois, sans rattachement aux versions et sans mécanique de mise à jour, devient rapidement une fiction documentaire. Il décrit un système qui n'existe plus, ou plus tout à fait. C'est un risque, pas une protection.
Ce que change le versioning
Versionner le Technical File en regard des versions du système est un changement de posture. La documentation cesse d'être une déclaration figée et devient une trajectoire, une suite de versions cohérentes, chacune rattachée à un état du système.
L'Evidence Pack adossé au Technical File
Le Technical File porte la description structurée. L'Evidence Pack porte les preuves associées : décisions, revues, validations humaines, références aux logs, aux jeux de tests, aux contrôles. Le premier sans le second reste fragile.
Ce qui doit rester humain
La cohérence finale du Technical File, l'arbitrage des sujets sensibles, la signature, l'engagement vis-à-vis du régulateur ou du marché : ces décisions ne sont pas automatisables. Une plateforme bien faite les éclaire ; elle ne les remplace pas.