CDCF — Catholic Digital Commons Foundation

Gouvernance-en-Code pour le Déploiement de Technologies Catholiques

Type de document Mémo de recherche
Statut Brouillon de travail — Discussion C-DART 1 des États-Unis
Relation Recherche complémentaire sous-jacente aux Critères de Vérification des Projets CDCF v0.2

Table des Matières

  1. L’Argument Principal
  2. Ce Qu’est la Gouvernance-en-Code
  3. Pourquoi les Institutions Catholiques en Ont Besoin
  4. La Pile à Trois Niveaux
  5. La Décision de Portail comme Artefact Principal
  6. Application au Déploiement de l’IA
  7. Application à la Conformité aux Normes
  8. Évaluation Honnête de la Préparation Institutionnelle
  9. Ce Que les Institutions Catholiques Peuvent Faire Maintenant
  10. Relation avec le CDCF
  11. Bibliographie

L’Argument Principal

La gouvernance technologique dans les institutions catholiques se trouve actuellement dans des PDF et des réunions de comité. Lorsqu’un diocèse, une école ou un hôpital catholique déploie un système technologique — qu’il s’agisse d’un outil d’IA, d’une plateforme de gestion paroissiale, d’une intégration de partage de données ou d’un projet de logiciel liturgique — le processus de gouvernance produit généralement un document qui indique que le système est approuvé. Ce document existe séparément du système qu’il gouverne. Il ne peut pas empêcher un déploiement non conforme. Il ne peut pas être validé automatiquement. Il ne peut que réagir après qu’un problème se soit produit.

La gouvernance-en-code est la pratique qui consiste à transformer ces documents de politique en spécifications exécutables par machine intégrées directement dans les pipelines de déploiement. La gouvernance devient partie intégrante de l’infrastructure. Ce changement est déjà en cours dans des environnements d’entreprise réglementés. La question pour les institutions catholiques est de savoir si elles participent à la définition de ce que ces spécifications codifient, ou si elles héritent de schémas de gouvernance laïques conçus sans référence à la théologie morale catholique, à l’autorité canonique, ou à la préoccupation préférentielle de l’Église pour les vulnérables.

Le principe s’applique sur deux dimensions de la mission du CDCF. Pour les déploiements technologiques, la gouvernance-en-code impose les critères de vérification comme des barrières strictes avant qu’un projet n’atteigne la production. Pour la conformité aux normes, la gouvernance-en-code vérifie que les projets sont conformes aux normes de données du CDCF — les identifiants et représentations partagés pour les célébrations liturgiques, les documents magistériels, les éditions des Écritures et les structures canoniques — automatiquement et en continu.

Ce Qu’est la Gouvernance-en-Code

Dans une architecture de gouvernance-en-code, les exigences politiques sont exprimées sous forme de schémas contrôlés par version (généralement JSON ou YAML) qui définissent exactement ce qu’un système technologique doit démontrer avant de pouvoir atteindre la production. Lorsqu’un développeur tente de déployer un projet, le pipeline de déploiement appelle ces schémas comme des barrières strictes.

La logique de la barrière est déterministe. Passer toutes les barrières et le projet se déploie. Échouer à une barrière et il ne se déploie pas. Chaque décision, réussite ou échec, est enregistrée dans une piste d’audit immuable que les régulateurs, les autorités diocésaines ou la direction institutionnelle peuvent examiner après coup.

Les schémas eux-mêmes définissent les critères de gouvernance : quelles preuves de test sont requises, quels domaines de données le système est autorisé à toucher, quel niveau de supervision humaine il opère, qui est la personne responsable nommée, quelles conditions nécessitent une escalade à une autorité supérieure, et — pour les projets dans des domaines couverts par les normes du CDCF — si les représentations de données du projet sont conformes aux schémas canoniques. Ce sont les mêmes questions que posent les Critères de Vérification du CDCF. La gouvernance-en-code est l’architecture technique qui transforme ces questions en barrières exécutables plutôt qu’en listes de contrôle consultatives.

Ceci est distinct de l’utilisation de l’IA pour gouverner la technologie. La décision de porte dans une architecture de gouvernance en tant que code est déterministe : un schéma passe ou ne passe pas, en fonction de critères explicites définis à l’avance par des autorités humaines. L’IA peut aider à la synthèse des preuves et à la mise en évidence des risques au sein du pipeline, mais la logique de la porte elle-même reste sous le contrôle défini par l’homme et appliqué par la machine.

Une préoccupation structurelle dans toute gouvernance technologique est l’écart de conformité entre l’intention réglementaire et la pratique de déploiement. Les cadres de gouvernance actuels partagent trois écarts récurrents : l’ambiguïté de la portée dans la définition des systèmes couverts, les exigences de conformité à un moment donné qui ne tiennent pas compte des systèmes qui évoluent après l’approbation initiale, et les asymétries d’information entre les régulateurs et les institutions déployant.1 La gouvernance en tant que code aborde directement les trois : les définitions de schéma établissent la portée avec précision, les schémas contrôlés par version évoluent avec le système qu’ils gouvernent, et les pistes de vérification immuables comblent l’écart d’information.

La Commission des Conférences Épiscopales de l’Union Européenne (COMECE) affirme que l’évaluation de la technologie d’un point de vue éthique « nécessite des principes de contrôle interne et une évaluation des risques en plus de la législation. »2 La gouvernance en tant que code est l’instanciation directe de ces principes de contrôle interne mandatés, traduisant l’évaluation éthique d’une activité de révision périodique en une exigence d’infrastructure continue et applicable.

Pourquoi les Institutions Catholiques en ont besoin

Le problème de fragmentation documenté dans le mémo compagnon sur la gouvernance numérique catholique à grande échelle est fondamentalement un problème d’encodage de la gouvernance — tant pour le déploiement technologique que pour l’infrastructure numérique.

Déploiement technologique. Chaque diocèse exprime ses valeurs de gouvernance technologique catholique dans un format différent, à un niveau de spécificité différent, pour des publics différents. Orange a rédigé une charte de conseil. Biloxi a rédigé un décret. Arlington a rédigé une politique scolaire. Aucun de ces instruments n’est lisible par machine. Aucun d’eux ne peut être validé automatiquement. Un fournisseur peut reconnaître les trois documents et déployer un système non conforme, car les documents n’ont pas de mécanisme d’application technique.

Conformité aux normes. Le même problème s’applique aux normes numériques. Même lorsque des identifiants canoniques partagés existent pour les célébrations liturgiques, les documents magistériels ou les éditions de la Scripture, un projet peut revendiquer la conformité sans être vérifié. Sans des schémas applicables par machine définissant à quoi ressemble la conformité à une norme CDCF, l’adoption des normes dépend d’une discipline volontaire plutôt que d’une application architecturale.

La gouvernance en tant que code change les relations structurelles. Un schéma de gouvernance canonique partagé — un ensemble de politiques exécutables par machine codant les principes de Antiqua et Nova,3 les principes de l’USCCB,4 les Directives Éthiques et Religieuses, et les normes de données CDCF en spécifications réutilisables contrôlées par version — permettrait à tout diocèse d’adopter la base partagée et de l’étendre avec des exigences locales. La subsidiarité est préservée car l’autorité locale gouverne toujours les décisions locales. La solidarité est atteinte car chaque institution opérant sur la base partagée est interopérable.

Un fournisseur servant des écoles catholiques serait confronté à un schéma canonique avec des extensions diocésaines optionnelles plutôt qu’à des dizaines de listes de contrôle incompatibles. Un système hospitalier catholique opérant au-delà des lignes diocésaines pourrait déployer uniformément car l’infrastructure de gouvernance est compatible à travers les juridictions. Un projet de logiciel liturgique pourrait vérifier sa conformité aux identifiants de calendrier CDCF dans le cadre de chaque construction. La gouvernance devient aussi portable que les outils qu’elle gouverne.

Le Rome Call for AI Ethics exige que des principes et des valeurs soient intégrés dans un cadre qui « sert de point de référence pour l’éthique numérique, guidant nos actions et promouvant l’utilisation de la technologie au bénéfice de l’humanité. »5 La couche de plateforme de gouvernance de cette architecture répond directement à cet appel, créant un point de référence partagé et tangible pour l’éthique numérique qui est applicable à travers les frontières institutionnelles catholiques plutôt que simplement aspirational.

La Pile à Trois Couches

Une architecture mature de gouvernance en tant que code pour le déploiement de technologies catholiques fonctionne à travers trois couches, chacune servant une fonction institutionnelle distincte.

Couche Fonction Utilisateurs principaux Rôle de la CDCF
Infrastructure Hooks de pipeline CI/CD, contrôleurs d’admission Kubernetes, logique de porte de déploiement, vérifications de validation des normes. Où les schémas s’exécutent comme des portes rigides et des pistes d’audit sont générées. Développeurs et équipes DevOps Contribue aux spécifications de schéma
Plateforme de gouvernance Bibliothèque de schémas : spécifications de politiques sous contrôle de version, logique de classification des risques, base de gouvernance canonique catholique, schémas de conformité aux normes de la CDCF. Où la théologie morale catholique et les exigences canoniques sont codées comme des critères lisibles par machine. Bureaux informatiques diocésains et responsables de la gouvernance Gère la base canonique partagée
Application Outils orientés vers l’institution : flux de travail d’intégration, tableaux de bord des risques, rapports de conformité aux normes, artefacts d’audit pour la direction diocésaine et les régulateurs externes. Administrateurs de paroisse et d’école Fournit des modèles et des outils

Ces trois couches correspondent directement aux trois niveaux de capacité institutionnelle que les organisations catholiques possèdent réellement. Une petite paroisse ou école fonctionne principalement au niveau de l’application, utilisant des outils de gouvernance sans avoir besoin de comprendre l’infrastructure sous-jacente. Un bureau informatique diocésain opère au niveau de la plateforme de gouvernance, adoptant et étendant des schémas canoniques pour le contexte local. Un grand système de santé catholique ou une université fonctionne au niveau de l’infrastructure, intégrant des portes de gouvernance dans ses propres pipelines CI/CD.

La Décision de Porte comme Artefact Principal

Le principe de conception le plus significatif dans ce cadre est que la décision de porte elle-même, la décision d’aller, d’aller conditionnellement, de ne pas aller, ou de différer, est considérée comme un artefact de première classe plutôt qu’un sous-produit du processus de révision.

Un artefact de décision de porte capture les preuves spécifiques assemblées, les niveaux de confiance attribués, les lacunes identifiées, le propriétaire de la décision humaine nommé, le raisonnement derrière le résultat, et les conditions sous lesquelles la décision a été prise. Il est immuable une fois enregistré. C’est le document qui répond à la question du régulateur, à la question de l’évêque, et à la question de la personne concernée : pourquoi ce système a-t-il été déployé, sous quelle autorité, et sur quelle base.

Cette conception reflète directement la norme canonique établie dans le Canon 1609, qui exige que les processus délibératifs produisent des conclusions écrites avec des raisons en droit et en fait, et que la capacité de révision et d’appel soit préservée.6 Un artefact de décision de porte est la mise en œuvre technique de cette exigence canonique.

L’immuabilité de la piste d’audit sert également une préoccupation institutionnelle spécifiquement catholique. La USCCB avertit que la technologie peut être mal utilisée pour “saper la dignité des personnes et le respect de la vérité” par la manipulation de l’information.7 Un enregistrement de décision de porte immuable garantit que si un système déployé se comporte de manière contraire à sa spécification de gouvernance, la responsabilité institutionnelle est claire, traçable, et préservée pour révision. La conséquence pratique des pistes d’audit non gouvernées est documentée dans les déploiements d’entreprise : lorsque un système de production récupère un document de politique remplacé sans provenance capturée, l’organisation ne peut pas reconstruire ce que le système a vu ou pourquoi, transformant la réponse aux incidents en conjectures judiciaires plutôt qu’en responsabilité basée sur des preuves.8

Les quatre états de décision portent des implications distinctes.

État de la décision Signification Exigence de documentation
Go Tous les critères de gouvernance satisfaits ; déploiement autorisé Preuves complètes des critères enregistrées
Conditional-go Déploiement autorisé sous réserve de conditions spécifiques dans un délai défini Conditions et calendrier spécifiés ; généralement utilisé lorsque la validation indépendante est en attente
No-go Un ou plusieurs critères n’ont pas été respectés ; déploiement bloqué Critères spécifiques et lacunes de preuves documentées
Defer Escalade à une autorité supérieure requise avant de procéder Autorité identifiée et raison spécifiée

Application au déploiement de l’IA

Le déploiement de l’IA est le domaine où la gouvernance en tant que code est la plus urgente et la plus techniquement mature.

Les chercheurs étudiant les échecs des systèmes multi-agents ont identifié 14 modes d’échec distincts répartis sur trois catégories (problèmes de conception de système, désalignement entre agents et défaillances de vérification des tâches) soulignant l’importance structurelle de la logique de porte déterministe plutôt que de l’examen de conformité médié par les agents.9 Les données d’enquête empiriques provenant de 306 praticiens de l’IA dans 26 domaines confirment que la fiabilité reste le principal défi de déploiement, 68 % des agents de production exécutant dix étapes ou moins avant qu’une intervention humaine ne soit requise.10 Ces résultats plaident en faveur d’architectures de gouvernance dans lesquelles des portes définies par l’homme et appliquées par la machine sont le principal mécanisme de contrôle plutôt que le jugement des agents.

La pression réglementaire renforce l’urgence. La loi sur l’IA de l’UE, avec des obligations clés pour les systèmes d’IA à haut risque entrant en vigueur en 2026, crée une demande structurelle pour une gouvernance de déploiement auditable dans les catégories d’IA à haut risque.11 Les soins de santé catholiques, l’éducation et les services sociaux opèrent directement dans ces catégories.

Cadre Juridiction Lacune clé
California SB 53 États-Unis (Californie) Ambiguïté de portée pour les systèmes couverts
New York RAISE Act États-Unis (New York) Conformité ponctuelle, pas de suivi post-approbation
U.S. AIREA Fédéral Asymétrie d’information entre les régulateurs et les déployeurs
Obligations GPAI de la loi sur l’IA de l’UE Union Européenne Les trois lacunes présentes à grande échelle

Une mise en œuvre de gouvernance en tant que code spécifique à l’IA encode les extensions de domaine de l’IA des Critères de Vérification du CDCF — divulgation des données d’entraînement, analyse des performances des sous-groupes, conditions limites canoniques — en tant que schémas applicables par machine au sein de la base canonique partagée. Cela est distinct de l’utilisation de l’IA pour gouverner l’IA : la logique de porte reste déterministe, et un pipeline gouverné par l’IA nécessiterait une gouvernance propre, créant une régression que l’application déterministe des schémas évite.

Application à la conformité aux normes

L’architecture de gouvernance en tant que code s’étend naturellement à la conformité aux normes de données du CDCF.

Lorsque la CDCF définit des identifiants canoniques pour les célébrations liturgiques (CLEDR), les documents magistériels (CMDDR) ou les éditions du Missel romain (CRMETDR), ces normes peuvent être exprimées sous forme de schémas de validation lisibles par machine. Un projet de logiciel liturgique qui prétend se conformer à CLEDR peut voir cette prétention vérifiée automatiquement dans son pipeline de construction. Une plateforme catéchétique qui fait référence aux documents magistériels peut valider ses identifiants par rapport au schéma CMDDR au moment du déploiement.

Cela déplace la conformité aux normes d’une affirmation documentaire (« nous suivons les normes de la CDCF ») à un fait architectural (« notre pipeline vérifie les normes de la CDCF à chaque construction »). La couche de gouvernance de la plateforme maintient les schémas canoniques, et la couche d’infrastructure les applique — la même architecture qui régit l’éthique du déploiement régit également l’interopérabilité des données.

Pour les institutions catholiques, cette intégration est significative. Un projet qui passe à la fois les critères de sélection et les critères de conformité aux normes porte un niveau d’assurance qu’aucun document de politique à lui seul ne peut fournir : il a été validé par rapport aux exigences de gouvernance catholique et il interopère avec l’infrastructure numérique partagée de l’Église, le tout vérifié par des preuves applicables par machine plutôt que par auto-attestation.

Évaluation honnête de la préparation institutionnelle

L’implémentation technique complète de la gouvernance en tant que code au niveau de l’infrastructure dépasse la capacité actuelle de la plupart des institutions catholiques, et exagérer cette capacité produirait le type d’écart de crédibilité en matière de gouvernance que ce cadre est conçu pour prévenir. La plupart des institutions catholiques, y compris les diocèses et systèmes de santé bien dotés, fonctionnent actuellement au mieux au niveau de l’application. Elles ont des documents de politique. Certaines ont des comités de révision. Très peu ont des schémas de gouvernance contrôlés par version. Aucune, à la connaissance de cette recherche, n’a de schémas de gouvernance catholique canoniques intégrés comme des barrières strictes dans les pipelines de déploiement CI/CD.

Cet écart représente l’opportunité, et c’est la raison pour laquelle les critères de sélection de la CDCF sont structurés de cette manière. Le critère 6 exige une spécification de gouvernance écrite et révisable ainsi qu’une compatibilité architecturale avec une future application. L’implémentation complète au niveau de l’infrastructure est aspirante à l’étape d’incubation. La spécification de gouvernance écrite aujourd’hui devient le schéma codé demain. Les critères sont conçus pour développer progressivement la capacité institutionnelle, rencontrant les institutions à leur maturité actuelle plutôt que d’exiger des capacités encore à développer.

Une critique soulevée lors des discussions de la session C-DART 1 mérite d’être reconnue directement : la gouvernance des soins de santé dans les institutions catholiques est principalement un problème légal et réglementaire plutôt qu’un problème d’ingénierie. HIPAA, FDA, CMS et la loi de l’État établissent le minimum. Cette critique est exacte, et ce cadre l’accepte. La gouvernance en tant que code fonctionne comme la couche technique qui rend la conformité à ces cadres auditable, reproductible et interopérable à travers les frontières institutionnelles catholiques. La distinction entre remplacer la réglementation et rendre la conformité techniquement applicable est la distinction qui rend cette approche crédible plutôt que démesurée.

Ce que les institutions catholiques peuvent faire maintenant

Étant donné l’évaluation honnête de la préparation institutionnelle actuelle, la contribution à court terme de cette recherche est une norme d’évaluation écrite qui fonctionne comme le précurseur d’un pipeline de gouvernance CI/CD de production plutôt que le pipeline lui-même.

Les critères de sélection de la CDCF représentent cette norme d’évaluation. Le critère 6 demande aux soumissionnaires de spécifier les niveaux d’autorité décisionnelle, les conditions d’escalade, les déclencheurs de révision humaine et les processus d’appel dans un document écrit et révisable. Cette spécification est la première étape vers un schéma exécutable par machine. Une institution qui a écrit une spécification de gouvernance rigoureuse pour un projet a accompli la majeure partie du travail intellectuel nécessaire pour encoder cette spécification en tant que schéma de gouvernance réutilisable.

La CDCF est positionnée pour maintenir la bibliothèque de schémas canoniques que les institutions individuelles étendent plutôt que de construire indépendamment. C’est la couche de solidarité décrite dans le mémo de fragmentation : une base partagée qui préserve l’autorité locale tout en rendant la gouvernance technologique catholique interopérable à grande échelle.

Trois actions concrètes découlent de cette recherche pour les institutions catholiques à tout niveau de maturité technique.

  1. Exiger des spécifications de gouvernance écrites pour chaque projet technologique en cours d’évaluation. Le format de spécification dans le Critère 6 des Critères de Vérification du CDCF fournit un modèle de départ.
  2. Contrôler les versions de ces spécifications. Même un document Word dans un lecteur partagé avec un numéro de version et un propriétaire nommé est une étape significative vers la discipline de la gouvernance en tant que code.
  3. Évaluer les projets technologiques pour la compatibilité des schémas : l’architecture du projet supporte-t-elle l’intégration des portes de gouvernance et la validation des normes, ou nécessite-t-elle de contourner les contrôles de gouvernance pour fonctionner ?

Relation avec le CDCF

La gouvernance en tant que code sert d’architecture d’application pour les deux piliers de la mission du CDCF.

Vérification des projets. Le Critère 6 des Critères de Vérification des Projets du CDCF est l’expression opérationnelle directe de cette recherche. Il exige une spécification de gouvernance de déploiement comme condition d’acceptation de l’incubation, avec le modèle de décision à quatre états (go, conditionnel-go, no-go, différer) comme cadre structurel pour cette spécification. Le Critère 8 étend le principe à l’architecture de déploiement des projets eux-mêmes, exigeant que les projets soient déployables au niveau approprié de l’autorité ecclésiale sans contourner leur conception de gouvernance fondamentale. Ensemble, les Critères 6 et 8 établissent les exigences de spécification de gouvernance qui positionnent les institutions catholiques à adopter une mise en œuvre plus complète de la gouvernance en tant que code à mesure que la capacité institutionnelle se développe.

Conformité aux normes. Le programme de Normes du CDCF définit les identifiants canoniques et les représentations de données que les projets logiciels catholiques devraient adopter. La gouvernance en tant que code fournit le mécanisme d’application : les normes exprimées sous forme de schémas lisibles par machine peuvent être validées automatiquement, déplaçant la conformité de l’auto-attestation à la vérification architecturale.

Bibliographie

  1. Joe Kwon et Stephen Casper, “Gaps de Déploiement Internes dans la Régulation de l’IA,” arXiv:2601.08005, soumis le 12 janvier 2026, révisé le 14 février 2026, https://arxiv.org/abs/2601.08005.↩︎

  2. Commission des Conférences Épiscopales de l’Union Européenne (COMECE), “Déclaration sur la Loi de l’IA de l’UE,” COMECE, 2024, https://church.mt/comece-on-the-artificial-intelligence-act-it-does-justice-to-the-ethical-foundations-of-the-eu/.↩︎

  3. Dicastère pour la Doctrine de la Foi et Dicastère pour la Culture et l’Éducation, Antiqua et Nova : Note sur la Relation entre l’Intelligence Artificielle et l’Intelligence Humaine (Cité du Vatican : Dicastère pour la Doctrine de la Foi, 28 janvier 2025), https://www.vatican.va/roman_curia/congregations/cfaith/documents/rc_ddf_doc_20250128_antiqua-et-nova_en.html.↩︎

  4. Conférence des Évêques Catholiques des États-Unis, Lettre Conjointe sur les Principes et Priorités de l’Intelligence Artificielle, 9 juin 2025, https://www.usccb.org/resources/joint-letter-artificial-intelligence-principles-and-priorities.↩︎

  5. Pape François, “Discours lors de la Signature de l’Appel de Rome pour l’Éthique de l’IA,” Cité du Vatican, 28 février 2020, https://www.vatican.va/content/francesco/en/speeches/2020/february/documents/papa-francesco_20200228_eticaartificiale.html.↩︎

  6. Code de Droit Canon, Canon 1609 (Cité du Vatican : Libreria Editrice Vaticana, 1983), https://www.vatican.va/archive/cod-iuris-canonici/eng/documents/cic_lib7-cann1501-1670_en.html.↩︎

  7. Conférence des Évêques Catholiques des États-Unis, Lettre Conjointe sur les Principes et Priorités de l’Intelligence Artificielle, 9 juin 2025, https://www.usccb.org/resources/joint-letter-artificial-intelligence-principles-and-priorities.↩︎

  8. Rick Hamilton, “La Gouvernance des Données pour l’IA Doit Être Exécutable,” hamiltonandboss.com (Substack), 2025, https://substack.com/@rickwritesai/p-189861656.↩︎

  9. Mert Cemri, Melissa Z. Pan, Yapei Yang, Aditya Agrawal, Tatsunori Hashimoto, Diyi Yang, Qian Yang, et Percy Liang, « Pourquoi les systèmes LLM multi-agents échouent-ils ? » arXiv:2503.13657, soumis le 17 mars 2025, https://arxiv.org/abs/2503.13657.↩︎

  10. Melissa Z. Pan, Mert Cemri, Lingjiao Chen, Matei Zaharia, James Zou, et Percy Liang, « Mesurer les agents en production », arXiv:2512.04123, soumis le 2 décembre 2025, révisé le 3 février 2026, https://arxiv.org/abs/2512.04123.↩︎

  11. Parlement européen et Conseil de l’Union européenne, Règlement (UE) 2024/1689 du Parlement européen et du Conseil établissant des règles harmonisées sur l’intelligence artificielle (Loi sur l’intelligence artificielle), Journal officiel de l’Union européenne, 12 août 2024, https://artificialintelligenceact.eu.↩︎