Nous avons publié l'intégralité de notre Vendor Assurance Pack — y compris ce que nous n'avons pas

Voici comment fonctionne réellement l'achat de logiciels dans une entreprise réglementée. Les opérations choisissent l'outil en semaine deux. La Qualité et la sécurité informatique commencent leur examen en semaine quatre. Le questionnaire arrive chez le fournisseur en semaine six — quarante onglets, avec une demande de catégorisation GAMP que le fournisseur n'a jamais couchée sur papier. Quelque part vers la semaine quatorze, tout le monde se met d'accord, et ce qui a bloqué n'a jamais été le produit.

Nous avons été suffisamment souvent dans cette situation pour conclure que l'ordre est mauvais. Nous avons donc publié les réponses en amont.

Contenu du document

Dix-huit sections, organisées pour qu'un examinateur puisse accéder directement à sa partie. Un responsable qualité a besoin de l'index QMS, de la catégorisation GAMP 5 et des mappages Annex 11 et Part 11. La sécurité informatique a besoin de la topologie d'hébergement, de l'architecture de sécurité et du CAIQ-Lite. Un DPO a besoin de la répartition responsable de traitement/sous-traitant, du registre des sous-traitants et de la section gouvernance de l'IA. Les achats ont besoin du statut de certification, de la posture de continuité et de la répartition des responsabilités. Le document s'ouvre sur un tableau indiquant à chacun les sections à consulter.

Les mappages de clauses en constituent le cœur. Chaque clause de Annex 11 — les dix-sept — avec ce que nous faisons à ce sujet et où se trouvent les preuves. Puis 21 CFR Part 11 : les contrôles §11.10, les dispositions relatives aux signatures §11.50 et §11.70, et les exigences en matière de signatures électroniques §11.100, §11.200 et §11.300. Deux de ces lignes sont marquées comme relevant de *votre* obligation et non de la nôtre, car elles ne peuvent pas être assumées par un fournisseur, et prétendre le contraire laisserait une lacune qui ne se révèle qu'au cours d'une inspection.

Et ce qui n'y figure pas

C'est la partie qui valait la peine d'écrire ce document. Le §13 est un tableau de statut de certification et le §17 est une liste complète des points ouverts ; ensemble, ils indiquent clairement :

• Nous ne détenons pas la certification SOC 2 Type II. Un programme combiné avec ISO 27001 est prévu, avec des mois cibles réalistes — et non la prétention qu'un audit est en cours.
• Nous ne détenons pas la certification ISO 27001.
• Notre pare-feu applicatif web ne dispose d'aucun jeu de règles. La politique est en mode Prévention, ce qui paraît rassurant mais, sans règles, ne filtre rien au niveau 7. Nous l'avons découvert lors de la vérification des informations pour ce document, et nous préférons le publier plutôt qu'un auditeur ne le trouve.
• La haute disponibilité n'est pas activée sur la base de données, la sauvegarde géo-redondante est désactivée, et nos RTO et RPO sont des objectifs internes plutôt que des engagements contractuels.
• Notre test de pénétration n'a pas été réalisé par un tiers accrédité CREST. Le test d'avril 2026 n'a retourné aucune constatation dans dix catégories OWASP ; il ne s'agissait pas d'un test indépendant accrédité, et nous le précisons là où un auditeur le cherchera.

Sur la différence entre conforme et certifié

Le dossier consacre un paragraphe à cette distinction, car elle est régulièrement brouillée sur ce marché. Annex 11 et 21 CFR Part 11 sont des exigences réglementaires, non des schémas de certification. Aucun organisme ne délivre de « certificat Annex 11 », et un fournisseur qui en propose un vend quelque chose qui n'existe pas. Ce qui peut réellement être attesté, c'est une mise en œuvre cartographiée clause par clause avec des artefacts justificatifs pour chaque ligne — ce que contient précisément ce dossier.

SOC 2 et ISO 27001 *sont* des schémas de certification. Nous ne les détenons pas. Nous ne nous décrivons donc pas comme certifiés, et les certifications de notre fournisseur d'infrastructure sont présentées comme les siennes plutôt que subrepticement comme les nôtres.

Tout ce qu'il contient a été vérifié, pas copié

Les documents de conformité se périment. Une région d'hébergement change, un écart est corrigé, un contrôle est renommé, et le document continue d'affirmer l'architecture de l'année passée avec la confiance de l'année en cours. Le nôtre avait commencé à le faire : un document interne du QMS décrivait encore un prestataire d'hébergement dont nous avions migré, et une page de notre propre site indiquait les mauvaises régions Azure.

Ainsi, chaque statut du dossier a été vérifié sur l'infrastructure de production en direct et le code source en direct le jour de la publication — les régions lues depuis l'abonnement, la politique de résidence lue depuis son affectation, la configuration de la périphérie lue depuis les en-têtes de réponse en direct, le comportement de la piste d'audit et de la signature lu depuis le code qui les implémente. Lorsque la vérification contredisait un document existant, la vérification l'a emporté. C'est également ainsi que nous avons découvert le problème du jeu de règles du pare-feu.

Le dossier est daté et comporte un engagement de révision : au moins tous les six mois, et réédité dès qu'un statut dans le tableau de certification ou la liste des points ouverts évolue.

Si vous êtes en charge de l'évaluation

Un document complémentaire existe. La Check-list de préparation aux audits GMP pour les opérations de cour est une auto-inspection en 101 points du périmètre de la cour — et son dernier domaine porte sur la qualification fournisseur de votre système de gestion de cour. Ce dossier est conçu pour répondre à ce domaine, que le fournisseur que vous évaluez soit nous ou non.

Si vous avez besoin d'un élément absent du dossier — l'ensemble complet du QMS sous NDA, des preuves de tests exécutés, un inventaire logiciel pour une version désignée, ou un CAIQ complété selon votre propre modèle — contactez-nous à admin@yardtwin.com. La liste des éléments disponibles sur demande figure au §18.