Il existe une forme particulière de paralysie autour de l’AI Act dans les entreprises intermédiaires. Le texte est long, les sanctions sont citées dans les titres de presse, et personne en interne ne peut affirmer avec autorité si tel projet est autorisé. Les projets s’arrêtent donc, pendant que les collaborateurs continuent d’utiliser les outils qu’ils ont trouvés eux-mêmes.
Dans presque tous les cas où l’on nous appelle, l’issue est la même et elle est sans drame : l’entreprise est déployeur, pas fournisseur ; presque rien de ce qu’elle exploite n’est à haut risque ; et les obligations qui s’appliquent réellement se satisfont en un mois environ.
Voici ce mois.
Jours 1 à 5 : l’inventaire, y compris ce que personne n’a validé
On ne peut pas classifier ce qu’on n’a pas listé. L’inventaire a trois sources, et sauter la troisième est l’erreur la plus fréquente.
La première est la liste des projets : ce que les métiers ont formellement proposé ou construit. La deuxième est la liste des fournisseurs : les fonctions d’IA à l’intérieur des logiciels que vous achetez déjà — l’assistant de votre CRM, la synthèse de votre outil de support, le scoring de votre outil de recrutement. Ce sont celles qui surprennent, car personne n’a décidé d’adopter l’IA ; elle est arrivée dans une note de version.
La troisième est le shadow AI. Demandez, sans reproche, ce que les gens utilisent réellement. Attendez-vous à ce que la réponse inclue au moins un assistant généraliste ayant vu des documents d’entreprise. L’apprendre pendant l’inventaire coûte bien moins cher que de l’apprendre pendant un incident.
Pour chaque système, notez : ce qu’il fait, qui l’utilise, quelles données y entrent, si la sortie affecte une personne, et qui l’a fourni.
Jours 6 à 10 : rôle et risque, système par système
Deux questions règlent l’essentiel du travail.
Êtes-vous fournisseur ou déployeur ? Vous êtes déployeur si vous utilisez un système d’IA sous votre propre autorité. Vous devenez fournisseur — avec un jeu d’obligations bien plus lourd — si vous y apposez votre nom, si vous modifiez substantiellement un système à haut risque, ou si vous transformez un modèle à usage général en usage à haut risque sous votre propre marque. Affiner un modèle pour un usage interne ne fait généralement pas de vous un fournisseur. Livrer ce modèle à vos clients comme une fonctionnalité, oui.
De quelle classe de risque relève-t-il ? Les pratiques interdites sont peu nombreuses et généralement évidentes une fois lues : notation sociale, certaines catégorisations biométriques, inférence d’émotions au travail et dans l’éducation, moissonnage non ciblé d’images faciales. Lisez la liste une fois au regard de votre inventaire et n’y revenez plus.
Le haut risque se définit par l’usage, pas par la technologie. Les cas qui rattrapent les entreprises ordinaires relèvent de l’emploi — tri de CV, attribution de tâches, décisions de promotion ou de rupture — et de l’accès aux services essentiels comme la notation de crédit. Un assistant qui rédige des courriels n’est pas à haut risque parce qu’il est habile ; un simple outil à base de règles qui filtre des candidatures peut l’être.
Consignez le raisonnement, pas seulement la conclusion. La décision consignée est le livrable.
Jours 11 à 15 : les obligations qui vous concernent réellement
Pour un déployeur d’un système à haut risque, les obligations centrales sont : utiliser le système conformément à la notice du fournisseur ; confier le contrôle humain à des personnes ayant la compétence et l’autorité pour l’exercer ; veiller à la pertinence des données d’entrée au regard de la finalité, dans la mesure où vous les maîtrisez ; surveiller le fonctionnement et informer le fournisseur et l’autorité des incidents graves ; conserver les journaux générés automatiquement ; et informer les travailleurs concernés avant la mise en service sur le lieu de travail. Certains déployeurs — organismes publics et entités privées fournissant des services publics, ainsi que les cas d’usage de crédit et d’assurance — doivent en outre réaliser une analyse d’impact sur les droits fondamentaux.
Pour les systèmes à risque limité, l’obligation est l’information : les personnes doivent savoir qu’elles interagissent avec un système d’IA, et les contenus synthétiques doivent être signalés comme tels.
Pour tout déployeur, l’article 4 impose la maîtrise de l’IA : les collaborateurs qui utilisent ces systèmes doivent en avoir une compréhension suffisante. Cela s’applique quelle que soit la classe de risque, depuis février 2025, et c’est l’obligation que la plupart des entreprises n’ont pas remarquée.
Jours 16 à 22 : les trois documents
La gouvernance n’a pas à être lourde, et une gouvernance lourde est la façon dont les projets meurent. Trois artefacts suffisent pour une entreprise de cette taille.
Un registre IA. Une ligne par système : nom, responsable, finalité, rôle, classe de risque, données utilisées, date de revue. Conservé là où les gens le mettront réellement à jour.
Une politique d’usage acceptable. Courte. Quels outils sont approuvés, ce qui peut et ne peut pas y être collé, ce qui doit être vérifié avant qu’une production ne sorte de l’entreprise, et à qui s’adresser. Écrite pour être lue en trois minutes.
Un circuit de validation. Un formulaire léger et un relecteur nommé pour les nouveaux cas d’usage, avec un engagement de délai — deux jours ouvrés, pas deux semaines. Si la validation est lente, les équipes la contourneront, et vous serez revenu au shadow AI avec de meilleurs formulaires.
Jours 23 à 27 : la maîtrise de l’IA, réellement délivrée
Deux séances : une pour les collaborateurs qui utilisent ces outils au quotidien, une pour ceux qui décident de les acheter. Un contenu propre à vos systèmes, pas générique. Ce que ces modèles font bien, comment ils échouent, ce qui ne doit jamais entrer dans un prompt, et ce que « contrôle humain » signifie dans votre contexte.
Consignez les présences. Cette trace est votre preuve au titre de l’article 4.
Jours 28 à 30 : le travail de sécurité que vous savez désormais nécessaire
L’inventaire aura fait apparaître au moins un point qui relève de la sécurité plutôt que de la conformité. C’est presque toujours le même : un assistant connecté à une base documentaire qui hérite de toutes les permissions trop larges jamais accordées.
Cadrez ce travail, même si vous ne pouvez pas le mener ce mois-ci. Un système d’IA capable de lire tout ce que l’un de vos collaborateurs peut lire n’est une question de conformité qu’après avoir été une question de contrôle d’accès.
Ce que vous avez à la fin
La liste de chaque système d’IA de l’entreprise, une classification défendable pour chacun avec le raisonnement consigné, trois documents de gouvernance courts, des équipes formées avec la trace pour le prouver, et un élément de backlog sécurité qui était invisible trente jours plus tôt.
C’est tout l’AI Act pour la plupart des déployeurs de taille intermédiaire. C’est un mois, pas un programme, et les entreprises qui le font cessent d’être bloquées — ce qui en est le bénéfice réel.