Le juriste demande une supervision humaine. Le développeur ajoute un bouton de validation. Le responsable métier explique que personne n’aura le temps de cliquer. En trois phrases, une réunion sur l’intelligence artificielle peut révéler le véritable obstacle à la conformité : les équipes utilisent les mêmes mots sans parler de la même chose. À l’horizon de septembre 2026, l’application progressive de l’AI Act européen rend cette difficulté décisive. Savoir traduire une règle en décision opérationnelle devient une compétence collective, aussi importante que la qualité du modèle.
Un calendrier réglementaire, plusieurs horloges internes
Entré en vigueur le 1er août 2024, le règlement européen sur l’intelligence artificielle organise une application par étapes. Les dispositions sur les pratiques interdites et la maîtrise de l’IA s’appliquent depuis le 2 février 2025. Une nouvelle étape, concernant notamment les modèles d’IA à usage général, est intervenue le 2 août 2025. Dans le calendrier initial du texte, le 2 août 2026 constitue le principal rendez-vous suivant, tandis que certaines obligations relatives aux systèmes à haut risque intégrés à des produits réglementés sont prévues pour août 2027.
Ces dates ne signifient pas que tous les outils basculent simultanément sous les mêmes obligations. Des dispositions transitoires existent, notamment pour certains systèmes ou modèles déjà commercialisés. Cette projection vers septembre 2026 s’appuie sur le règlement adopté et son calendrier initial : d’éventuelles évolutions ultérieures doivent être vérifiées dans les textes applicables. La première compétence utile est donc de savoir poser la question avant d’annoncer une échéance.
Or chaque fonction possède sa propre horloge. Le juridique raisonne en entrée en application, les développeurs en versions, les achats en renouvellements contractuels et les métiers en objectifs trimestriels. Sans coordination, chacun peut respecter son calendrier tout en faisant manquer celui du projet.
Traduire les usages avant de traduire le droit
Prenons un cas fictif : une entreprise veut utiliser un assistant pour préparer le recrutement. « Il fait seulement gagner du temps », assure le métier. Mais que fait-il exactement ? Rédige-t-il une annonce, résume-t-il les candidatures ou classe-t-il les personnes à recevoir ? Ces usages ne soulèvent pas les mêmes questions. Certains systèmes destinés au recrutement ou à la sélection figurent parmi les catégories à haut risque du règlement, sous réserve des conditions et exceptions prévues.
Le dialogue doit donc commencer par des verbes, pas par des étiquettes commerciales. Qui fournit les données ? Que produit le système ? Qui consulte le résultat ? Quelle décision peut en découler ? Une démonstration sur un parcours complet vaut souvent mieux qu’une présentation annonçant une solution « responsable ». Elle permet au juriste de comprendre l’usage réel et au développeur de voir les conséquences de ses choix.
La qualification des acteurs exige la même précision. L’entreprise est-elle fournisseur, déployeur, ou susceptible de changer de rôle en modifiant substantiellement un système ? Acheter une interface ne permet pas, à lui seul, de répondre. Un vocabulaire partagé n’efface pas la complexité juridique ; il évite de la dissimuler derrière des raccourcis.
Transformer une obligation en décision vérifiable
La traduction devient utile lorsqu’elle relie une exigence à une action observable. « Garantir la supervision humaine » reste abstrait. Déterminer qui peut interrompre le traitement, avec quelles informations et quelle autorité, constitue déjà une décision de conception. Pour les systèmes concernés, la supervision ne se résume pas à placer une personne à la fin du processus : encore faut-il qu’elle puisse comprendre, contester et corriger.
Dans notre recrutement fictif, l’équipe pourrait examiner une proposition : ne pas laisser un classement automatique déclencher seul un rejet. Ce choix n’est ni une recette universelle ni une garantie de conformité. Il oblige cependant à discuter du temps disponible, de l’accès aux candidatures originales et du risque que le recruteur suive mécaniquement la recommandation.
Un support commun peut tenir en cinq lignes par sujet :
- L’exigence : ce que demande le texte applicable, avec sa source.
- Le risque concret : ce qui pourrait arriver à une personne ou au processus.
- La décision : ce que l’équipe construit, limite ou abandonne.
- La preuve : le test, le document ou la trace permettant de vérifier ce choix.
- Le responsable : la personne chargée de l’action et de son suivi.
Cette grille évite deux impasses : le mémo juridique que personne ne sait appliquer et la fonctionnalité livrée sans lien explicite avec l’obligation. Elle rend aussi les désaccords visibles avant qu’ils ne deviennent des incidents.
Organiser le désaccord plutôt que chercher un consensus mou
La réunion efficace n’est pas celle où tout le monde approuve. C’est celle où les objections deviennent exploitables. Le juriste doit pouvoir distinguer une interdiction, une obligation assortie de conditions et une zone d’incertitude. Le développeur doit préciser ce qui est techniquement possible, coûteux ou impossible à garantir. Le métier doit reconnaître quand son organisation empêche un contrôle pourtant prévu dans l’interface.
La reformulation croisée constitue un exercice simple : chacun explique la contrainte de l’autre avant de défendre sa solution. « Si je comprends bien, vous avez besoin de retrouver les éléments ayant conduit à cette recommandation. » Ou : « Votre équipe ne peut pas réexaminer chaque dossier dans le délai actuel. » Cette discipline révèle les faux accords, sans exiger que chacun devienne expert du domaine voisin.
Il faut ensuite une règle d’arbitrage. Qui décide de réduire le périmètre, de reporter le lancement ou d’accepter un risque résiduel dans les limites du droit ? La décision mérite une trace courte : options examinées, raisons du choix, réserves et conditions de réexamen. La conformité gagne alors une mémoire, plutôt qu’une collection de validations dispersées.
Former pour rendre chacun capable d’agir
L’article 4 du règlement prévoit des mesures visant à assurer un niveau suffisant de maîtrise de l’IA pour les personnels et autres personnes concernés, en tenant compte notamment de leurs connaissances, de leur expérience et du contexte d’utilisation. Cette logique dépasse la formation générique identique pour tous. Savoir rédiger une instruction à un assistant ne suffit pas à comprendre quand son résultat devient dangereux ou inapproprié.
Un acheteur doit savoir quelles informations demander au fournisseur. Un responsable opérationnel doit reconnaître une dérive d’usage. Un développeur doit comprendre pourquoi certains tests doivent reproduire les conditions réelles. Des ateliers courts, construits autour d’un incident plausible, peuvent faire émerger ces réflexes : résultat inventé, recommandation contestée ou changement de modèle chez un prestataire.
On peut alors observer des progrès concrets sans fabriquer un indicateur magique : les demandes sont-elles mieux décrites ? Les alertes arrivent-elles avant le lancement ? Les équipes savent-elles à qui transmettre un doute ? La qualité du dialogue se mesure surtout à ce qu’il permet de décider.
Et maintenant ? À mesure que l’application du règlement avance, les organisations pourraient découvrir que leur meilleur investissement n’est pas un comité supplémentaire, mais quelques habitudes solides : décrire les usages, reformuler les contraintes, documenter les arbitrages et rouvrir les décisions lorsque le système change. L’enjeu prospectif est là : faire de la conformité une capacité d’adaptation partagée, plutôt qu’un contrôle terminal dont personne ne comprend vraiment les conclusions.
