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.

*Mise à jour du 12 octobre 2026 : le dossier est réédité en v1.2 après que chaque statut a été re-vérifié par rapport au code source en production, à la configuration Azure en direct et à nos pages publiques. La version 1.1 (23 août 2026) et son édition de reformulation uniquement 1.1.1 surestimaient plusieurs contrôles ; la v1.2 les corrige et liste chaque correction. Lorsqu'un élément n'a pas pu être vérifié, le dossier le signale et l'énonce sous sa forme la plus prudente.*

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. Un engagement SOC 2 peut être envisagé sur demande client une fois la certification ISO 27001 obtenue — pour une base clients européenne, ISO 27001 est le certificat demandé en priorité lors des revues fournisseurs.
• Nous ne détenons pas encore la certification ISO 27001. Le SMSI a été ouvert en août 2026 ; l'audit de certification de Phase 2 est prévu pour février 2027 et l'obtention du certificat est ciblée pour le T1 2027. Jusqu'à l'obtention du certificat, le dossier indique *non détenu*.
• Notre pare-feu applicatif web applique cinq règles personnalisées de limitation de débit, mais aucun ensemble de règles OWASP géré. Le niveau Standard de Front Door ne permet pas d'en associer un — cela nécessite le niveau Premium, prévu lors de la refonte de la production.
• La haute disponibilité n'est pas activée sur la base de données, et nos RTO et RPO sont des objectifs internes plutôt que des engagements contractuels ; la disponibilité mensuelle de 99,5 % sur les plans payants est contractuelle. L'exercice de restauration est exécuté et documenté (une restauration complète de la production mesurée à moins de 7 minutes), et des sauvegardes chiffrées mensuelles sont conservées jusqu'à 7 ans selon une politique d'immuabilité temporelle bloquant la suppression et l'écrasement (politique pas encore verrouillée).
• Aucun test de pénétration indépendant n'a encore été réalisé. Un test est prévu, avec un re-test, et son périmètre est défini. Notre audit interne de code en boîte blanche d'octobre 2026 a effectivement identifié des vulnérabilités, dont deux de niveau Critique ; les deux findings Critiques sont corrigés en production. Les travaux d'avril 2026 correspondaient à des tests de sécurité fonctionnelle internes, et non à un test de pénétration.

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 pack a été vérifié le jour de la publication par rapport au code source exécuté en production, à la configuration Azure en direct et à nos pages publiques — les régions lues depuis l'abonnement, la politique de résidence lue depuis son affectation, la configuration edge lue depuis les en-têtes de réponse en direct, le comportement de la piste d'audit et des signatures lu depuis le code qui les implémente. Lorsque la vérification contredisait un document existant, la vérification a prévalu. C'est ainsi qu'est née la v1.2 : la révérification de la v1.1 a révélé des affirmations qui n'avaient jamais été exactes, et cette édition les corrige.

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.