Pourquoi un sociologue de 1980 éclaire l’AI Office en 2026
Quand la Commission européenne publie un Code de bonnes pratiques pour les modèles d’intelligence artificielle à usage général, puis rappelle que les pouvoirs d’exécution de l’AI Office entreront en jeu à partir du 2 août 2026, le débat public se polarise rapidement.
D’un côté, certains y voient une bureaucratie de plus, susceptible de freiner l’innovation européenne. De l’autre, d’autres considèrent que l’Europe tente enfin d’imposer des garde-fous à des technologies devenues trop puissantes pour être laissées aux seules entreprises qui les conçoivent.
David Collingridge permet de déplacer la question.
Dans The Social Control of Technology, publié en 1980, ce sociologue britannique ne demande pas seulement s’il faut réguler une technologie. Il pose une question plus profonde : à quel moment peut-on encore la réguler efficacement ?
Son idée, connue sous le nom de « dilemme de Collingridge », tient en une tension simple.
Au début, une technologie est encore malléable. On peut modifier ses choix de conception, ses usages, ses règles d’accès, ses standards techniques. Mais on connaît mal ses effets sociaux réels.
Plus tard, les effets deviennent visibles. Les risques apparaissent, les usages se stabilisent, les dépendances se multiplient. Mais la technologie est déjà installée. Elle devient plus difficile à corriger, car elle repose sur des investissements, des infrastructures, des habitudes professionnelles, des contrats, des marchés et des rapports de force.
C’est exactement le problème posé par les modèles d’IA généralistes : fallait-il les encadrer très tôt, au risque de réguler dans le brouillard ? Ou attendre que leurs effets soient visibles, au risque de découvrir trop tard que l’on ne peut plus les transformer sans coûts massifs ?
Le dilemme de Collingridge, en une formule
Le dilemme de Collingridge repose sur deux moments.
Premier moment : la phase précoce. La technologie est encore ouverte. Les choix techniques ne sont pas totalement verrouillés. Les usages ne sont pas massivement installés. Les acteurs publics pourraient encore influencer la trajectoire.
Mais c’est aussi le moment où l’on sait le moins. On ignore les effets sociaux à long terme. On ne sait pas encore quels risques seront majeurs, quelles dérives seront marginales, quels usages deviendront dominants. Réguler trop tôt peut donc conduire à mal viser, à bloquer des innovations utiles ou à produire des règles inadaptées.
Deuxième moment : la phase tardive. Les effets deviennent plus lisibles. Les risques sont documentés. Les usages réels permettent de mieux comprendre ce qu’il faut encadrer.
Mais la technologie a changé de statut. Elle n’est plus seulement un objet technique. Elle est devenue une infrastructure économique, sociale et politique. Elle est intégrée dans des services, des administrations, des entreprises, des outils de travail, des plateformes, parfois même dans les habitudes quotidiennes des utilisateurs.
À ce stade, réguler reste possible, mais le coût augmente. Il faut corriger des systèmes déjà déployés, convaincre des acteurs puissants, modifier des contrats, adapter des chaînes d’intégration, former des professionnels, créer des audits, contrôler des documents parfois opaques.
Le dilemme n’est donc pas : régulation ou innovation. Il est : réguler quand on ne sait pas encore, ou réguler quand on ne peut presque plus.
L’AI Act et le Code GPAI : une tentative de sortie du piège
L’AI Act européen peut être lu comme une tentative de répondre à ce dilemme par étapes.
Le règlement européen sur l’intelligence artificielle est entré en vigueur en 2024. Les obligations concernant les modèles d’IA à usage général, ou GPAI pour General-Purpose AI, commencent à s’appliquer en 2025. Le Code de bonnes pratiques GPAI, publié en juillet 2025, sert d’outil volontaire pour aider les fournisseurs à se conformer aux obligations prévues par le règlement. À partir du 2 août 2026, les pouvoirs d’exécution de la Commission, via l’AI Office, doivent permettre un contrôle plus ferme.
Ce calendrier n’est pas seulement administratif. Il révèle une stratégie temporelle.
L’Europe ne peut pas faire comme si les grands modèles de langage n’existaient pas encore. ChatGPT, Claude, Gemini, Mistral, Llama et d’autres systèmes sont déjà intégrés dans les usages. Des entreprises construisent leurs services autour de ces modèles. Des administrations expérimentent. Des développeurs intègrent des API. Des citoyens les utilisent pour écrire, coder, apprendre, résumer, traduire ou organiser leur travail.
Il est donc trop tard pour réguler comme si la technologie était encore entièrement malléable.
Mais il n’est pas forcément trop tard pour agir sur ce qui reste modifiable : la transparence documentaire, les évaluations de risques, les politiques de sécurité, les procédures de red teaming, les obligations liées au droit d’auteur, les informations transmises aux intégrateurs, les responsabilités des fournisseurs et les mécanismes de coopération avec le régulateur.
Le Code GPAI s’inscrit précisément dans cet espace intermédiaire. Il ne refait pas les modèles depuis zéro. Il cherche à encadrer leur gouvernance.
Ce que Collingridge appelle le contrôle social de la technique
Collingridge refuse l’idée selon laquelle la technique avancerait seule, comme une force autonome, et que la société n’aurait plus qu’à s’adapter après coup. Pour lui, une technologie est aussi le produit de choix humains : choix de conception, choix de financement, choix d’usage, choix de régulation, choix institutionnels.
Le contrôle social de la technologie ne signifie pas que l’État doit tout décider. Il signifie que les sociétés démocratiques doivent conserver une capacité d’orientation sur les techniques qui les transforment.
Ce contrôle peut prendre plusieurs formes.
Il peut passer par la conception : modifier un système tant qu’il est encore possible d’agir sur ses paramètres, ses garde-fous, ses journaux d’activité, ses seuils de sécurité, ses mécanismes d’évaluation.
Il peut passer par les institutions : imposer des obligations, organiser des audits, clarifier les responsabilités, structurer les marchés publics, fixer des conditions d’accès ou de diffusion.
Il peut aussi passer par l’information : documenter ce que fait un système, produire des preuves, rendre certains risques visibles, permettre à des tiers de vérifier les affirmations des fournisseurs.
Dans le cas des modèles GPAI, cette dernière dimension est centrale. Une régulation qui ne dispose pas d’informations fiables devient rapidement symbolique. Elle donne l’impression de contrôler sans toujours disposer des moyens réels de vérifier.
Sommes-nous encore dans une phase malléable ?
La première question collingridgeenne à poser au Code GPAI est simple : que peut-on encore modifier ?
Pour l’architecture profonde des très grands modèles, la réponse est limitée. Les choix d’entraînement, les jeux de données, les infrastructures de calcul, les coûts GPU, les secrets industriels et les performances commerciales rendent une refonte complète difficile.
Mais tout n’est pas verrouillé.
Les fournisseurs peuvent encore modifier leurs procédures d’évaluation. Ils peuvent améliorer leurs politiques de gestion des risques. Ils peuvent documenter davantage les capacités et limites de leurs modèles. Ils peuvent renforcer les tests de sécurité. Ils peuvent clarifier les conditions contractuelles proposées aux intégrateurs. Ils peuvent mieux informer les entreprises qui réutilisent leurs modèles dans des systèmes à haut risque.
Le Code GPAI cible donc moins le cœur invisible des modèles que leur environnement de gouvernance.
C’est une nuance essentielle. Il ne s’agit pas d’un bouton d’arrêt. Il s’agit d’un ensemble de dispositifs destinés à rendre l’IA plus auditable, plus documentée, plus responsable et plus prévisible dans ses conditions d’usage.
Autrement dit, l’Europe régule ce qui reste politiquement et techniquement négociable.
Ce que le Code cherche à produire : de l’information vérifiable
Collingridge insiste sur une difficulté majeure : au début, on ne sait pas encore ce qu’il faudrait savoir.
Dans le domaine de l’IA, cette difficulté est évidente. Les risques ne se limitent pas à une panne technique. Ils concernent aussi la désinformation, les biais, la cybersécurité, l’automatisation de tâches sensibles, l’usage frauduleux, la concentration du marché, le droit d’auteur, la dépendance des administrations ou encore l’opacité des chaînes de décision.
Face à cela, le Code GPAI ne produit pas seulement des obligations formelles. Il vise aussi à créer des capteurs institutionnels.
Les rapports, les évaluations, les documentations techniques, les politiques de copyright, les procédures de sécurité et les engagements de suivi ne sont pas de simples documents administratifs. Ils sont censés permettre au régulateur de voir ce qui resterait autrement invisible.
Mais c’est aussi là que se trouve la limite.
Si les documents sont trop généraux, s’ils ne sont pas vérifiables, s’ils reposent uniquement sur les déclarations des entreprises, ou si les données d’entraînement demeurent trop opaques, alors le risque est de créer une illusion de contrôle.
La vraie question n’est donc pas : un fournisseur a-t-il publié un document ?
La vraie question est : ce document permet-il à un tiers compétent de tester, comparer, contester ou vérifier ce qui est affirmé ?
C’est ici que le Sentier du Savoir rejoint l’actualité. Lire un dossier GPAI devrait ressembler à la lecture critique d’un article scientifique : quelles sont les hypothèses ? Quelle méthode est utilisée ? Quelles limites sont reconnues ? Que peut-on reproduire ? Que reste-t-il invérifiable ?
Qui paie le coût du « trop tard » ?
La troisième question posée par Collingridge est politique : lorsque la régulation arrive tard, qui supporte le coût de l’ajustement ?
Dans le cas de l’IA, ce coût peut être déplacé vers plusieurs acteurs.
Les petites entreprises peuvent devoir modifier leurs outils si une API change, si un modèle devient non conforme, ou si de nouvelles obligations documentaires apparaissent.
Les États peuvent se retrouver en négociation permanente avec de grandes plateformes technologiques, souvent extra-européennes.
Les intégrateurs peuvent devoir prouver la conformité de systèmes construits sur des briques qu’ils ne maîtrisent pas entièrement.
Les citoyens, eux, peuvent subir les effets des erreurs, des biais, des usages abusifs ou des dépendances numériques avant que les mécanismes d’audit ne soient pleinement opérationnels.
Le Code GPAI cherche à déplacer une partie de ce coût vers les fournisseurs des modèles généralistes. C’est un point important. Dans une chaîne d’IA, celui qui déploie l’outil n’est pas toujours celui qui possède les informations les plus décisives sur le modèle.
Faire peser toutes les obligations sur les intégrateurs reviendrait à demander à ceux qui utilisent une infrastructure de documenter ce que seuls les concepteurs peuvent réellement connaître.
Sur le papier, le Code tente donc de rééquilibrer la responsabilité. Reste à savoir si ce rééquilibrage sera effectif dans la pratique.
Le Code GPAI : solution ou symptôme ?
Le Code GPAI peut être lu de deux manières.
Première lecture : c’est une solution partielle au dilemme de Collingridge. Il permet d’agir avant que tous les standards techniques ne soient finalisés. Il offre aux fournisseurs une voie de conformité. Il réduit l’incertitude juridique. Il crée un espace de dialogue entre l’industrie, les experts et l’AI Office. Il donne au régulateur un cadre pour transformer des principes juridiques en pratiques plus concrètes.
Deuxième lecture : c’est aussi un symptôme du dilemme. Si un Code volontaire est nécessaire, c’est précisément parce que la régulation arrive dans un environnement déjà mouvant, complexe et partiellement verrouillé. Les standards harmonisés ne sont pas tous stabilisés. Les modèles évoluent vite. Les chaînes d’intégration sont mondiales. Les capacités techniques des régulateurs doivent encore se renforcer.
Le Code est donc à la fois un outil de gouvernance et un aveu de transition.
Il ne faut ni le surestimer, ni le mépriser. Il ne garantit pas, à lui seul, une IA démocratiquement maîtrisée. Mais il peut devenir un point d’appui si ses engagements sont précis, si les audits sont sérieux, si les autorités disposent de moyens suffisants, et si la société civile peut examiner les preuves.
Collingridge ne conclurait probablement ni à une victoire démocratique, ni à une capture industrielle sans examen. Il demanderait plutôt : qui participe à l’élaboration des règles ? Qui peut vérifier les déclarations ? Qui bénéficie des marges de souplesse ? Qui supporte les coûts lorsque les risques se matérialisent ?
Collingridge face à Winner : deux lectures complémentaires
Langdon Winner pose une question célèbre : les artefacts ont-ils une politique ?
Autrement dit, une technologie n’est jamais neutre. Elle favorise certains usages, certains acteurs, certaines formes d’organisation sociale. Une infrastructure technique peut renforcer un pouvoir sans jamais prononcer un discours politique explicite.
Collingridge, lui, pose une autre question : à quel moment peut-on encore renégocier cette politique inscrite dans la technique ?
Les deux lectures se complètent.
Winner aide à voir ce que l’IA installe : dépendance aux grands fournisseurs, centralisation des infrastructures, asymétrie entre concepteurs et utilisateurs, pouvoir des plateformes, effets de standardisation.
Collingridge aide à voir quand il est encore possible d’agir : avant que les choix techniques deviennent irréversibles, ou au moins avant que les dépendances deviennent trop coûteuses à défaire.
Appliquée au Code GPAI, cette double lecture est précieuse.
Winner nous invite à demander quelle politique est déjà inscrite dans les modèles et leurs infrastructures.
Collingridge nous invite à demander quelles parties de cette politique peuvent encore être discutées, documentées, limitées ou corrigées.
Ce que ce cadre change pour le lecteur
Face à un communiqué affirmant qu’un modèle est « conforme au Code GPAI », la réaction critique ne doit être ni la confiance automatique, ni le rejet automatique.
Le bon réflexe consiste à poser des questions précises.
Quand le fournisseur a-t-il structuré ses procédures de sécurité : avant ou après la menace d’un contrôle effectif ?
Quelle partie du système peut encore être modifiée sans réentraînement massif ?
La documentation permet-elle une vérification par un tiers ?
Les risques systémiques sont-ils décrits de manière concrète ou par formules générales ?
Les limites du modèle sont-elles reconnues ou masquées derrière un discours de performance ?
Les engagements sur le droit d’auteur sont-ils vérifiables ou simplement déclaratifs ?
Les audits sont-ils indépendants ?
Les intégrateurs disposent-ils d’informations suffisantes pour assumer leurs propres responsabilités ?
Ces questions ne sont pas techniques au sens étroit. Elles relèvent de la culture démocratique. Elles permettent au lecteur de ne pas confondre conformité annoncée et contrôle réel.
Le Sentier du Savoir : apprendre à lire les preuves de l’IA
Ce triptyque peut devenir un exercice pratique du Sentier du Savoir.
Il ne s’agit pas seulement de suivre l’actualité européenne de l’IA. Il s’agit d’apprendre à lire les documents de gouvernance comme on apprend à lire une source historique, un article scientifique ou un discours politique.
Un dossier GPAI doit être interrogé.
Que promet-il ?
Que prouve-t-il ?
Que laisse-t-il dans l’ombre ?
Qui parle ?
Qui vérifie ?
Qui paie si la promesse échoue ?
Le lecteur devient alors autre chose qu’un spectateur de la régulation. Il devient un observateur critique des mécanismes par lesquels une société tente de reprendre prise sur une technologie déjà installée.
C’est exactement l’esprit du Sentier du Savoir : transformer l’actualité en exercice de discernement.
Conclusion : la régulation comme bataille du temps
David Collingridge n’a pas prédit ChatGPT. Il n’a pas anticipé les modèles de langage, les agents conversationnels ou les infrastructures cloud de l’IA générative.
Mais il a décrit une difficulté qui demeure centrale : les démocraties doivent souvent choisir entre intervenir tôt avec peu d’information, ou intervenir tard avec peu de marge de manœuvre.
Le Code GPAI et l’échéance du 2 août 2026 sont une tentative européenne de gérer cette tension. L’Union européenne ne régule pas une technologie qui serait encore à l’état de laboratoire. Elle tente d’encadrer des modèles déjà diffusés, déjà intégrés, déjà économiquement puissants.
Cette stratégie est imparfaite, mais elle révèle une chose essentielle : réguler l’IA n’est pas actionner un interrupteur. C’est organiser une série d’ajustements dans le temps, entre connaissance incomplète, pouvoir limité et responsabilité politique.
Le dilemme de Collingridge nous oblige à regarder la régulation autrement. Non comme un frein abstrait à l’innovation. Non comme une garantie automatique de sécurité. Mais comme une course difficile contre le verrouillage des techniques.
La vraie question devient alors : avons-nous encore assez de temps, assez d’informations et assez de pouvoir collectif pour orienter l’IA avant qu’elle ne devienne une infrastructure impossible à discuter ?
Repères de sources
- David Collingridge, *The Social Control of Technology* (Frances Pinter, 1980)
- David Collingridge, « Technology and Risk », in *Readings in Risk* (T. S. Glickman & M. Gough, eds., Resources for the Future, 1990)
- Commission européenne, Code GPAI : Contents of the Code
- AI Act Consortium, Introduction to the Code of Practice
Dans ce triptyque
Pour voir comment cette grille de lecture éclaire le sujet du jour :
- Revenir à l’actualité : Code of Practice GPAI : l’Europe entre signature volontaire et compte à rebours du 2 août 2026
- Prolonger avec le Sentier du Savoir : Tester les preuves d’un dossier GPAI : méthode en six étapes
Vous devez être connecter pour pouvoir voter
