Parcours intelligence artificielle

Lorsqu’on essaie pour la première fois un système d’IA générative, la réaction la plus courante oscille entre deux extrêmes : l’émerveillement de celui qui croit avoir devant lui une encyclopédie infaillible qui converse, et la méfiance de celui qui, ayant relevé la première erreur, écarte le tout comme un jouet peu fiable. Les deux réactions naissent du même malentendu : juger l’outil sans savoir comment il fonctionne. Un grand modèle de langage est entraîné en l’exposant à d’énormes quantités de texte — livres, articles, pages web, documents de toute nature — avec une tâche en apparence modeste : apprendre à prévoir quel mot vient ensuite, dans chaque contexte possible. De cet exercice, répété sur des milliards d’exemples, le modèle tire une représentation statistique du langage si riche qu’elle lui permet d’écrire, de résumer, de traduire, de répondre à des questions. Il n’y a, derrière les réponses, ni archive consultée entrée par entrée, ni programmeur ayant prévu cette question précise : il y a un mécanisme de prévision du texte qui produit, à chaque fois, la continuation la plus adaptée à la demande reçue.

La différence avec le logiciel traditionnel n’est pas de degré mais de nature : le logiciel de gestion exécute des règles, le modèle produit de la plausibilité. Un programme de comptabilité additionne les factures parce que quelqu’un a écrit l’instruction de les additionner, et si le résultat est faux, il existe quelque part une règle à corriger. Un modèle génératif, devant la même question, compose une réponse qui ressemble aux réponses justes qu’il a vues pendant l’entraînement — et il le fait en général bien, parce que les réponses justes constituent la part prépondérante de ses exemples. Mais « ressembler à la bonne réponse » et « être la bonne réponse » restent deux choses différentes, et le modèle ne dispose d’aucun mécanisme interne qui les distingue : la même assurance de ton accompagne l’affirmation exacte et l’affirmation inventée. Il est désormais fréquent que les utilisateurs de ces outils s’en aperçoivent précisément ainsi, en trouvant un détail erroné au sein d’une réponse par ailleurs excellente. Cela ne rend pourtant pas l’outil inutilisable : cela impose de l’utiliser en sachant ce que l’on peut en attendre, comme pour tout collaborateur dont on connaît les points forts et les limites.

Les deux mythes opposés doivent donc être dissipés ensemble. L’IA générative n’est pas un oracle : elle ne « sait » pas au sens où sait un professionnel qui a étudié et vérifié, et présenter ses réponses comme des vérités certifiées est une erreur de méthode avant d’être une erreur de prudence. Mais elle n’est pas non plus un jouet : sur des tâches d’écriture, de synthèse, de reformulation, de première analyse d’un document, la qualité du travail est réelle et le gain de temps est concret. La posture correcte est celle que l’on adopte avec un collaborateur brillant et pas encore expérimenté : on lui confie volontiers le premier jet, pas la signature. Cette image a toutefois elle aussi une limite, et il convient de la déclarer : le collaborateur humain apprend de ses erreurs dans la relation avec nous, tandis que le modèle, d’une conversation à l’autre, ne conserve en règle générale aucune mémoire — la supervision ne peut donc pas se relâcher avec le temps par habitude, comme ce serait le cas avec une personne.

Pourquoi il est utile de le savoir

• Comprendre le mécanisme — prévision du texte, et non consultation d’une archive — permet de prévoir où l’outil rendra bien (écrire, résumer, reformuler) et où la prudence s’imposera (faits, chiffres, références précises).
• La distinction entre plausible et vrai est le critère pratique pour décider ce qui doit être vérifié avant usage : tout ce qui est vérifiable et porte à conséquence mérite un contrôle humain.
• Celui qui, dans l’entreprise, part de l’un des deux mythes — confiance aveugle ou refus total — tend à mal utiliser l’outil dans les deux cas : une explication honnête du fonctionnement est le premier investissement de formation, avant même toute règle d’usage.

Imaginons une petite entreprise manufacturière qui doit répondre au questionnaire de qualification d’un client étranger potentiel. L’employée administrative, pour aller plus vite, demande à un chatbot de préparer la réponse, et obtient un texte excellent : professionnel, bien structuré, convaincant. À l’intérieur, pourtant, se trouvent une certification décrite par un sigle que l’entreprise ne possède pas dans cette version, une donnée de capacité de production vraisemblable mais jamais réellement calculée, et la référence à une pratique sectorielle exprimée avec un tel naturel qu’elle semble évidente — et que personne dans l’entreprise ne saurait documenter. Rien, dans le ton, ne distingue les parties fiables des parties inventées : le texte est uniformément sûr de lui. Si le document part tel quel, l’entreprise a déclaré à un client des choses inexactes sans que personne n’ait jamais décidé de le faire. Tel est le scénario typique de l’hallucination en contexte professionnel : non pas l’erreur grossière que chacun remarquerait, mais le détail plausible niché dans un travail par ailleurs bon, où la qualité de l’ensemble fait baisser la garde précisément sur le point qu’il fallait contrôler.

Hallucinations, biais et limites temporelles ne sont pas des défauts de jeunesse que la prochaine version éliminera : ce sont des caractéristiques structurelles de la manière dont ces systèmes fonctionnent. L’hallucination découle du mécanisme même de la génération — le modèle produit toujours la continuation la plus plausible, même lorsque rien dans ses données n’étaye une réponse, et dans ce cas la plausibilité comble le vide. Les biais découlent des données d’entraînement, qu’aucune collecte, si vaste soit-elle, ne rend neutres. La limite temporelle découle du fait que l’entraînement est un processus qui se clôt, tandis que le monde continue. Les versions successives atténuent ces phénomènes, parfois de manière notable, et il serait incorrect de le nier ; toutefois, atténuer n’est pas éliminer, et une organisation qui règle ses contrôles en comptant sur la disparition du problème les règle sur un espoir. La conséquence opérationnelle est nette : le contrôle humain et la vérification des sources ne sont pas une phase transitoire dans l’attente de modèles parfaits, mais une composante permanente de tout usage professionnel de ces outils.

Comment vit-on, en pratique, avec des limites que l’on ne peut pas éliminer ? Avec la même méthode qu’avec tout risque connu : en sachant où il se concentre. Les points fragiles d’une réponse générée sont identifiables à l’avance — les références précises (sources, sigles, noms, dates), les chiffres, tout ce qui est récent, tout ce qui sera déclaré à des tiers — et c’est là que la vérification doit se concentrer, en remontant à la source originale et sans se contenter de demander confirmation à l’outil lui-même, qui tend à confirmer avec la même assurance que celle avec laquelle il s’est trompé. Le reste — la structure du texte, le ton, la fluidité — peut être volontiers laissé à la machine. La méthode ne fonctionne toutefois que si elle devient une habitude partagée et non le scrupule d’un seul : si, dans l’entreprise, une seule personne vérifie et les autres non, le niveau de contrôle effectif est celui de la personne la moins prudente.

Pourquoi il est utile de le savoir

• L’erreur la plus coûteuse n’est pas l’erreur évidente mais l’erreur plausible : la vérification doit se concentrer sur les références, les chiffres et les données récentes, c’est-à-dire sur les points où l’hallucination se cache le mieux.
• Demander au modèle si sa réponse est correcte n’est pas une vérification : la confirmation arrive avec la même assurance que l’erreur. Vérifier signifie remonter à la source originale.
• Puisque ces limites sont structurelles, les contrôles doivent être conçus comme une partie stable du processus — qui vérifie, quoi, avant quel usage — et non comme une précaution provisoire dans l’attente d’un meilleur outil.

Jusqu’ici, nous avons parlé de systèmes qui produisent du texte : on pose une question, on lit la réponse, et toute conséquence pratique passe par une décision humaine. Les agents IA marquent une étape supplémentaire. Un agent reçoit un objectif — « prépare les réponses aux demandes de documentation arrivées hier », « rassemble les données pour le devis et remplis le formulaire » — et le poursuit seul, en le décomposant en étapes : il lit les messages, ouvre les documents nécessaires, extrait les informations, remplit, prépare. À chaque étape, il décide de la suivante en fonction de ce qu’il a trouvé, sans que chaque mouvement ait été prévu par quelqu’un. Il est désormais fréquent que les outils proposés aux entreprises incorporent des fonctions de ce type, parfois sans même les appeler « agents » : l’assistant qui trie le courrier, le système qui prépare seul les dossiers répétitifs. L’avantage est évident — non plus une suggestion à recopier, mais un travail accompli — et il explique l’intérêt qui entoure cette évolution. Mais c’est précisément cet avantage qui impose de bien comprendre ce que l’on remet à l’outil : non plus seulement une question, mais une part d’activité opérationnelle.

Avec un agent, l’erreur ne reste pas à l’écran : elle devient une action accomplie. C’est la conséquence directe de tout ce qui a été vu au chapitre précédent. Les hallucinations, les biais, la variabilité des réponses ne disparaissent pas quand le modèle cesse de répondre et commence à agir ; ils changent de destination. La référence inventée qui, dans un chat, serait restée un texte à corriger peut, au sein d’un agent, finir dans un formulaire rempli et transmis ; l’interprétation erronée d’un message peut se traduire par une réponse partie vers le mauvais destinataire. Et puisque l’agent enchaîne plusieurs étapes, une erreur commise au début se propage aux étapes suivantes, qui construisent dessus avec l’habituelle, imperturbable cohérence. C’est pourquoi l’autonomie doit être dosée, et non accordée en bloc : le point de contrôle humain, naturel avec un chatbot — c’est nous qui lisons la réponse avant de l’utiliser —, doit être réintroduit délibérément avec un agent, en décidant à quels points de la chaîne l’agent doit s’arrêter et montrer ce qu’il s’apprête à faire. Mais la réaction inverse serait elle aussi une erreur, c’est-à-dire exiger une confirmation humaine à chaque pas : un agent qui demande la permission pour tout ne fait rien gagner, et la supervision réduite à des clics répétés cesse vite d’être une véritable supervision.

La notion à retenir est celle de périmètre : la liste explicite de ce que l’agent peut faire seul et de ce qui exige une confirmation. Le critère directeur est la réversibilité, corrigée par le bon sens : préparer, classer, trier, proposer sont des activités que l’on peut déléguer, parce qu’une erreur se corrige ; envoyer, signer, payer, supprimer, communiquer vers l’extérieur sont des seuils qu’il convient de garder sous un feu vert humain. Un périmètre sérieux n’est pas un vœu mais une configuration : il est inscrit dans les paramètres de l’outil, pas seulement dans les intentions de son utilisateur, et il est réexaminé lorsque l’expérience montre qu’il est trop large ou trop étroit. Reste, en arrière-plan, la question que tout entrepreneur se pose dès qu’il imagine un agent au travail : et s’il se trompe, qui en répond ? Nous la renvoyons à dessein au chapitre 8, où le sujet est traité en entier ; qu’il suffise ici de dire que la réponse commence précisément par le périmètre, parce que la délégation que l’on peut défendre est celle que l’on a su décrire.

Pourquoi il est utile de le savoir

• Avant d’adopter un outil, il convient de se demander s’il se contente de répondre ou s’il agit : beaucoup de produits récents incorporent des fonctions d’agent sans le déclarer sous ce nom, et le niveau de contrôle nécessaire change en conséquence.
• Le périmètre — quoi tout seul, quoi avec confirmation — doit être décidé et configuré avant la mise en service, en utilisant la réversibilité de l’action comme premier critère de délégation.
• La supervision doit se concentrer sur les seuils qui comptent (envois, signatures, paiements, communications à des tiers), et non se diluer sur chaque étape : trop de confirmation use l’attention autant que trop d’autonomie.

Il y a encore quelques années, la tentative d’escroquerie se reconnaissait à ses erreurs : un italien approximatif, un logo flou, une adresse électronique manifestement inventée. Cette marge de sécurité s’est refermée. Aujourd’hui, un système d’intelligence artificielle reconstruit une voix à partir de quelques secondes d’enregistrement, anime un visage dans une visioconférence, écrit un message impeccable dans son lexique et cohérent avec les habitudes de son destinataire. Les formes récurrentes sont au nombre de trois. La première est l’escroquerie au faux dirigeant : la voix de l’administrateur ordonne au responsable administratif un paiement urgent et confidentiel. La deuxième est la fausse vidéo du personnage connu — un journaliste, un représentant d’une institution — qui apparaît en train de promouvoir un investissement sûr : ce sont souvent des interventions télévisées authentiques, altérées ; la Polizia Postale, la Banca d’Italia et la Consob ont publié des avertissements explicites sur ce phénomène, en précisant que les messages attribués à ces autorités sont faux. La troisième est le message confectionné sur mesure, construit sur des informations réellement publiques — une commande en cours, un fournisseur habituel, le nom d’un collègue — et qui, pour cette raison, n’éveille les soupçons de personne.

La défense contre ces escroqueries n’est pas technologique, elle est organisationnelle : il ne s’agit pas de reconnaître le faux, mais de rendre inutile le fait qu’il soit crédible. Chercher l’imperfection dans l’image ou dans le son est une bataille déjà perdue, parce que la qualité des contenus artificiels s’améliore plus vite que la capacité à la percevoir. Ce qui, en revanche, ne vieillit pas, ce sont quatre garde-fous élémentaires, que toute entreprise peut adopter sans coûts. Le premier est la vérification par un canal différent : à la demande reçue par téléphone, on répond en rappelant le numéro interne connu, jamais celui d’où provient l’appel, et à une demande arrivée par courrier électronique on ne réplique pas en appuyant sur « répondre ». Le deuxième est la double autorisation écrite pour les paiements au-delà d’un seuil fixé par l’entreprise, sans exceptions accordées à l’urgence. Le troisième est un mot de passe convenu à l’avance entre la direction et l’administration, et — dans la sphère personnelle — un mot convenu en famille, parce que la même technique alimente les fausses demandes d’aide attribuées à un fils ou à un petit-fils. Le quatrième est culturel, et doit être énoncé dans l’entreprise : celui qui s’arrête pour vérifier ne commet pas un manque de confiance, et ne subira jamais un reproche pour l’avoir fait.

Reste le plan de la réaction, qui doit être préparé avant et non improvisé après. Dans l’entreprise, il doit être clair pour tous qui l’on appelle en premier — la banque — et que personne ne doit craindre de signaler l’erreur dès qu’il s’aperçoit qu’il l’a commise : le retard avec lequel la tromperie est admise est, en pratique, le facteur qui rend le plus souvent l’argent irrécupérable. Sur le plan juridique, deux éléments méritent d’être connus même de qui ne s’occupe pas de droit. Diffuser sans consentement des images, des vidéos ou des voix falsifiées au moyen de systèmes d’intelligence artificielle, de nature à tromper sur leur authenticité, et causer ce faisant un préjudice injuste à une personne constitue aujourd’hui une infraction autonome, punie d’un à cinq ans d’emprisonnement et poursuivie en règle générale sur plainte de la personne lésée (art. 612-quater du Code pénal italien, introduit par la loi du 23 septembre 2025, n° 132 — la loi italienne sur l’IA). Et les obligations de transparence du règlement européen sur l’intelligence artificielle, applicables depuis le 2 août 2026, imposent au déployeur qui génère ou manipule des images, des sons ou des vidéos constituant des deepfake de faire savoir que le contenu est artificiel (art. 50, par. 4, premier alinéa, du règlement (UE) 2024/1689) ; pour les œuvres manifestement artistiques, créatives, satiriques ou fictives, l’obligation se réduit à la divulgation de l’existence du contenu généré, de manière à ne pas entraver la jouissance de l’œuvre. Aucune des deux normes ne restitue toutefois l’argent d’un virement parti : elles servent à punir et à rendre reconnaissables les contenus, non à remplacer l’appel de vérification que personne n’a passé.

Pourquoi il est utile de le savoir

• La voix et le visage de quiconque a un rôle visible dans l’entreprise sont déjà du matériel disponible : la défense ne peut pas consister à reconnaître le faux, mais à ne jamais décider un paiement sur la base d’un seul canal de contact.
• L’urgence et la confidentialité, lorsqu’elles apparaissent ensemble dans une demande de paiement, ne sont pas des circonstances fortuites : elles sont la technique même de l’escroquerie, et doivent être traitées comme le premier indice.
• La procédure de réaction — la banque immédiatement, puis la plainte pénale et la conservation de toute trace — doit être écrite et connue avant d’être nécessaire : dans l’urgence, on exécute ce qui est déjà décidé, non ce que l’on improvise.

Le règlement (UE) 2024/1689 — l’acte que tout le monde appelle AI Act — n’est pas une loi sur la technologie, mais une loi sur l’usage qu’on en fait. C’est la clé pour le lire sans s’y perdre. Le texte définit avant tout deux positions subjectives, et fait dépendre d’elles presque tout : le fournisseur est celui qui met son nom ou sa marque sur un système et le porte sur le marché ; le déployeur est celui qui l’utilise sous sa propre autorité dans l’exercice d’une activité professionnelle (art. 3, points 3 et 4, du règlement (UE) 2024/1689). La quasi-totalité des entreprises clientes du Cabinet se trouve dans la seconde position. Il existe cependant un cas où la première position s’assume sans le vouloir : l’entreprise qui fait développer un logiciel par des tiers et le distribue sous sa propre marque est fournisseur, non simple utilisateur, et dès lors la charge des obligations change sensiblement. Sur ce point, il convient de s’arrêter avant de signer un contrat de développement, pas après. Quant au périmètre objectif, le règlement définit le « système d’IA » comme un système automatisé, doté d’une marge d’autonomie, qui déduit des entrées reçues la manière de générer des sorties telles que des prévisions, des contenus, des recommandations ou des décisions (art. 3, point 1) : un tableur aux formules déterministes n’en relève pas, un modèle qui génère des textes ou des scores, si.

Le report décidé en juillet 2026 a déplacé une partie du calendrier, il n’a pas suspendu le règlement : celui qui lit « AI Act reporté » et en conclut « je n’ai rien à faire » prend une mauvaise décision sur une prémisse fausse. Le règlement (UE) 2026/1744, publié le 24 juillet 2026 et entré en vigueur le 27 juillet 2026, a réécrit une partie de l’art. 113 : les obligations relatives aux systèmes à haut risque de l’annexe III, qui auraient dû s’appliquer le 2 août 2026, arriveront le 2 décembre 2027, et celles relatives aux systèmes de l’annexe I le 2 août 2028. Le législateur européen a motivé ce choix par le retard dans la disponibilité des normes techniques et des orientations et par le retard dans la constitution des autorités nationales compétentes, qui auraient rendu l’entrée en application onéreuse et peu efficace. Mais la date générale d’application du règlement, fixée au 2 août 2026, n’a pas été touchée, pas plus que les dates anticipées du 2 février 2025 et du 2 août 2025. Le tableau qui en résulte, aujourd’hui, est celui d’un règlement en grande partie opérationnel, avec un chapitre — le plus exigeant — qui arrivera dans un peu plus d’un an.

Les pratiques interdites de l’art. 5 méritent une énumération explicite, parce qu’elles sont déjà applicables depuis le 2 février 2025 et que leur violation relève du palier de sanctions le plus élevé : techniques subliminales ou délibérément manipulatrices qui altèrent substantiellement le comportement en causant un préjudice important ; exploitation des vulnérabilités dues à l’âge, au handicap ou à la situation sociale et économique ; notation sociale produisant des traitements préjudiciables dans des contextes sans lien avec ceux où les données ont été collectées, ou en tout état de cause injustifiés ou disproportionnés ; évaluation prédictive du risque d’infraction fondée uniquement sur le profilage ou sur des traits de personnalité ; création ou développement de bases de données de reconnaissance faciale par la collecte non ciblée d’images provenant d’internet ou de la vidéosurveillance ; reconnaissance des émotions sur le lieu de travail et dans les établissements d’enseignement, sauf motifs médicaux ou de sécurité ; catégorisation biométrique qui déduit la race, les opinions, l’appartenance syndicale, les convictions, la vie sexuelle ou l’orientation sexuelle ; identification biométrique à distance « en temps réel » dans des espaces accessibles au public à des fins répressives, sauf les hypothèses limitativement énumérées et autorisées (art. 5, par. 1, points a à h). Pour une PME, les pièges concrets se trouvent dans la notation sociale et dans la reconnaissance des émotions : un logiciel qui analyse les émotions ou l’« engagement » des salariés en visioconférence, ou un système interne de notation comportementale, tombe sous l’interdiction même s’il est proposé comme un simple outil de productivité.

Il reste à signaler une date rapprochée, le 2 décembre 2026, qu’il vaut la peine de garder distincte parce qu’elle cache deux échéances différentes que les commentaires tendent à confondre. La première concerne les nouvelles interdictions insérées dans l’art. 5 par le règlement (UE) 2026/1744, qui deviendront applicables ce jour-là. La seconde, tout à fait séparée, est le délai dans lequel les fournisseurs de systèmes génératifs déjà mis sur le marché avant le 2 août 2026 doivent se conformer à l’obligation de marquage des sorties synthétiques (art. 111, par. 4, introduit par le règlement (UE) 2026/1744) : c’est une obligation du fournisseur, non du déployeur, et l’entreprise utilisatrice n’a rien à faire, sinon s’attendre à ce que les outils qu’elle utilise se mettent en conformité. Toutefois, précisément parce que le chapitre III sur le haut risque arrivera en 2027 et en 2028, les choix d’achat que les entreprises font maintenant — un logiciel de sélection du personnel, un outil d’évaluation de la clientèle — doivent se faire dès aujourd’hui avec ces règles à l’esprit : un contrat signé en 2026 produira ses effets quand les obligations seront pleinement exigibles, et le renégocier alors coûte bien plus cher que de poser les bonnes questions maintenant.

Pourquoi il est utile de le savoir

• La position de déployeur n’est pas une position neutre : elle s’assume du seul fait d’utiliser un système d’IA dans l’activité professionnelle, sans aucun acte formel et sans que personne ne le notifie à l’entreprise.
• Le report décidé en 2026 concerne exclusivement les systèmes à haut risque : bâtir sur lui une attente généralisée signifie rester découvert précisément sur les obligations déjà applicables, qui sont aussi les plus faciles à violer par inattention.
• Distribuer sous sa propre marque un système fait développer par des tiers déclenche la qualification de fournisseur (art. 3, point 3) : c’est une circonstance à vérifier avant de définir le montage contractuel avec la société de développement, non en aval.

Vue du côté de l’entreprise qui utilise l’IA sans la développer, la matière se réduit à trois questions ordonnées : que dois-je faire dans tous les cas, que dois-je déclarer, et qu’est-ce qui change si l’outil que j’ai choisi relève des systèmes à haut risque. Sur le premier point, le règlement demande aujourd’hui moins que dans sa version de 2024. L’art. 4, réécrit par le règlement (UE) 2026/1744, n’impose plus de garantir « dans toute la mesure du possible un niveau suffisant » de maîtrise de l’IA, mais de prendre des mesures destinées à en soutenir le développement, calibrées sur les compétences du personnel, sur le contexte d’usage et sur les personnes à l’égard desquelles les systèmes sont utilisés ; et il précise que nul n’est tenu de garantir un niveau spécifique à quiconque. La raison de cet allègement, déclarée par le législateur européen, est que des obligations rigides ne conviendraient pas à tous les types de fournisseurs et de déployeurs et produiraient des charges disproportionnées, surtout pour les entreprises les plus petites. Il reste toutefois une obligation, applicable depuis le 2 février 2025, et il reste conseillé de documenter les mesures adoptées : un registre des sessions de formation et des instructions opérationnelles écrites sur l’usage des outils sont la trace la plus simple à produire.

Les obligations de transparence de l’art. 50 sont la partie de l’AI Act qui touche aujourd’hui, concrètement, presque chaque entreprise, et elles doivent être lues en distinguant avec précision qui en est chargé. Les systèmes destinés à interagir directement avec des personnes physiques doivent être conçus de manière que l’interlocuteur sache qu’il parle avec un système d’IA, et cela incombe au fournisseur (art. 50, par. 1). Les sorties synthétiques — audio, image, vidéo, texte — doivent être marquées dans un format lisible par machine comme générées ou manipulées artificiellement, et cela aussi incombe au fournisseur (art. 50, par. 2), à l’exclusion des cas où l’IA remplit une fonction d’assistance à l’édition standard sans modifier substantiellement l’entrée. Il faut toutefois rappeler au préalable une limite qui précède l’obligation d’information : l’art. 5, par. 1, point f), interdit l’usage de systèmes de reconnaissance des émotions sur le lieu de travail et dans les établissements d’enseignement, sauf motifs médicaux ou de sécurité — interdiction applicable depuis le 2 février 2025 et relevant du palier de sanctions le plus élevé —, de sorte que l’obligation d’informer les personnes exposées à des systèmes de reconnaissance des émotions ou de catégorisation biométrique (art. 50, par. 3) ne concerne que les contextes où l’usage reste permis et ne légitime pas l’analyse des émotions des salariés. Pèse en outre sur le déployeur l’obligation de faire connaître le caractère artificiel des deepfake publiés (art. 50, par. 4, premier alinéa). Le second alinéa du même paragraphe contient ensuite la disposition la plus utile à expliquer aux clients : celui qui publie un texte généré par l’IA pour informer le public sur des questions d’intérêt public doit le déclarer, mais l’obligation ne s’applique pas si le contenu a fait l’objet d’une révision humaine ou d’un contrôle éditorial et si une personne physique ou morale en détient la responsabilité éditoriale. Toutes les informations doivent être fournies de manière claire et reconnaissable au plus tard au moment de la première interaction ou exposition (art. 50, par. 5).

Le chapitre du haut risque n’est pas encore exigible, mais il conditionne déjà les choix d’achat. À partir du 2 décembre 2027 pour les systèmes de l’annexe III et du 2 août 2028 pour ceux de l’annexe I, le déployeur devra utiliser le système conformément à la notice d’utilisation, confier la surveillance humaine à des personnes dotées des compétences, de la formation et de l’autorité adéquates, garantir la pertinence et la représentativité des données d’entrée lorsqu’il les contrôle, surveiller le fonctionnement et suspendre l’usage en le signalant aux autorités dans les cas prévus, conserver les journaux générés automatiquement pendant au moins six mois, informer les représentants des travailleurs et les travailleurs concernés avant de mettre en service un système à haut risque sur le lieu de travail, et informer les personnes physiques soumises à l’usage du système lorsque celui-ci adopte ou assiste des décisions qui les concernent (art. 26 du règlement (UE) 2024/1689). Sur le front du travail, il convient toutefois d’éviter une erreur récurrente : une obligation d’information envers le travailleur existe déjà aujourd’hui, parce que l’art. 11 de la loi du 23 septembre 2025, n° 132 n’en crée pas une nouvelle mais renvoie à l’art. 1-bis du décret législatif 152/1997, qui était déjà applicable. Toutefois, sur le plan national des sanctions, le cadre n’est pas complet : la loi 132/2025 désigne l’AgID et l’ACN comme Autorités nationales pour l’intelligence artificielle, en confiant à l’ACN la surveillance, y compris les activités d’inspection et de sanction (art. 20), mais l’attribution formelle du pouvoir d’infliger les sanctions de l’art. 99 est renvoyée à un décret délégué que le Conseil des ministres a approuvé à titre définitif le 4 août 2026 et qui, à notre connaissance à la date de cette page, n’est pas encore publié à la Gazzetta Ufficiale ; le terme de la délégation, fixé au 10 octobre 2026, reste soumis aux mécanismes de prorogation prévus par la loi pour l’examen parlementaire. Dire qu’en Italie les sanctions de l’AI Act sont déjà pleinement opérationnelles serait inexact ; dire que l’Italie n’a pas désigné ses autorités le serait tout autant.

Pourquoi il est utile de le savoir

• L’obligation de maîtrise de l’IA est aujourd’hui une obligation de moyens, non de résultat : des mesures proportionnées et documentées suffisent, mais l’absence totale de mesures reste une violation d’une norme applicable depuis le 2 février 2025.
• Sur les obligations de transparence, la répartition compte plus que le contenu : ce qui concerne les chatbots et le marquage des sorties relève du fournisseur et doit être exigé par contrat ; ce qui concerne les deepfake publiés relève de l’entreprise et n’est délégable à personne.
• Si le logiciel a une incidence sur le recrutement, la gestion ou l’évaluation du personnel, ou sur la solvabilité de personnes physiques, on part du principe qu’il est à haut risque : la charge d’avoir documenté le contraire pèse sur le fournisseur, et doit être demandée par écrit avant l’achat.

Le point de départ est que la protection des données personnelles n’a pas attendu l’AI Act et n’en suit pas le calendrier. Le règlement (UE) 2016/679 s’applique depuis 2018 et continue de s’appliquer à l’identique à quiconque utilise des outils d’IA sur des données se rapportant à des personnes : clients, fournisseurs, candidats, salariés. Il en découle un ordre de priorité inverse de celui auquel l’entreprise s’attend : on vérifie d’abord la conformité au RGPD, qui est d’ores et déjà pleinement exigible, et l’on ne s’interroge qu’ensuite sur les obligations de l’AI Act, en partie différées. Le premier contrôle est le plus élémentaire et le plus négligé : savoir où finissent les données. Un service d’IA hébergé par un tiers implique un transfert d’informations hors des systèmes de l’entreprise, et avant de l’adopter il faut lire les conditions du service pour établir qui traite les données et à quelles fins, si elles sont conservées et pour combien de temps, et si le fournisseur les utilise pour l’entraînement de ses propres modèles. Ce dernier aspect est celui sur lequel l’entreprise peut le plus agir : lorsque le fournisseur propose des paramètres excluant l’usage des contenus à des fins d’entraînement, l’exclusion doit être activée et le choix documenté, car c’est une mesure organisationnelle qui réduit concrètement l’exposition.

La règle opérationnelle la plus efficace, et aussi la plus facile à faire respecter, est qu’on n’insère pas dans un service externe des données se rapportant à des tiers sans base juridique et sans avoir vérifié les conditions du service. Le collaborateur qui demande à un outil d’IA de résumer un contrat, de reformuler une lettre de contestation disciplinaire ou d’analyser une liste de positions débitrices traite des données de personnes qui n’ont aucun rapport avec ce fournisseur. La question à se poser n’est pas de savoir si l’outil est fiable, mais si ce traitement était permis. Il vaut la peine d’expliciter trois interdits pratiques, qui couvrent la quasi-totalité des incidents réels : on n’insère pas de documents contenant des données de santé, judiciaires ou relevant en tout cas des catégories particulières, sauf dans le cadre d’un traitement expressément prévu et évalué ; on n’insère pas de listes nominatives de clients ou de salariés à des fins d’analyse non déclarées dans la notice d’information ; on n’utilise pas d’outils choisis de sa propre initiative en dehors de ceux autorisés par l’entreprise. Trois lignes d’instruction interne, communiquées et conservées, valent plus que n’importe quelle déclaration de principe.

Reste le cas le plus délicat, celui où l’IA n’élabore pas des informations mais décide sur des personnes. Si un système sélectionne des candidatures, attribue une note à un client ou détermine l’issue d’une demande, et que la décision produit des effets juridiques ou affecte la personne de manière significative de façon similaire, on entre dans le champ de l’art. 22 du règlement (UE) 2016/679, avec tout ce qui s’ensuit en matière de base juridique admise, de garanties à assurer et d’informations à fournir. Dans ces mêmes cas, la condition de l’analyse d’impact de l’art. 35 est souvent réunie elle aussi, et les deux démarches doivent être menées ensemble : l’AI Act prévoit du reste expressément que le déployeur d’un système à haut risque utilise les informations reçues du fournisseur pour s’acquitter de l’obligation d’analyse d’impact au titre de l’art. 35 du RGPD (art. 26, par. 9, du règlement (UE) 2024/1689). Les deux évaluations se complètent, elles ne se dupliquent pas. Il faut toutefois dire avec franchise que la qualification n’est pas toujours nette : établir si une intervention humaine est effective ou purement formelle, et si un effet est « significatif de façon similaire », est un jugement qui admet des marges d’appréciation. C’est précisément pourquoi la meilleure défense n’est pas une réponse assurée, mais une décision motivée et conservée : si l’entreprise peut montrer sur quels éléments elle a raisonné et quelles garanties elle a mises en place, la discussion se déplace du fait de ne pas avoir évalué vers le fond de l’évaluation.

Pourquoi il est utile de le savoir

• Le report des obligations sur le haut risque n’offre aucun abri sur le front des données personnelles : les art. 13, 14, 22 et 35 du règlement (UE) 2016/679 s’appliquent aujourd’hui, exactement comme ils s’appliquaient avant l’AI Act.
• Le choix des données qui peuvent sortir de l’entreprise doit être opéré en amont et mis par écrit : laissé à l’individu au moment de l’usage, il devient une décision prise sans informations et sans trace.
• Lorsque le service permet d’exclure l’usage des contenus pour l’entraînement, activer ce paramètre et en conserver la preuve est l’une des rares mesures qui ne coûtent rien et que l’on peut effectivement démontrer en cas de contestation.

La question que les clients posent en premier — « si le système se trompe, qui paie ? » — a une réponse plus simple qu’on ne le craint et plus inconfortable qu’on ne l’espère. Il n’existe, en l’état, aucune norme permettant d’imputer le dommage au système : répond celui qui l’a mis en fonction dans son activité, et vis-à-vis du client final répond l’entreprise. Un exemple comparé l’illustre mieux que n’importe quel énoncé abstrait, et il doit être introduit avec sa mise en garde : il s’agit d’une décision étrangère, rendue en février 2024 par un organe canadien de résolution des litiges de faible valeur, dépourvue de toute autorité dans l’ordre juridique italien, et utilisable seulement comme exemple de la manière dont un problème identique a été traité ailleurs. Un passager avait demandé des renseignements au chatbot du site d’Air Canada et reçu l’indication d’un tarif préférentiel que la politique réelle de la compagnie ne permettait pas d’obtenir rétroactivement ; la compagnie se défendit en soutenant que le chatbot était une entité distincte, responsable de ses propres actes. L’argument fut rejeté : le chatbot fait partie du site, et l’entreprise répond des informations que son propre site fournit. La condamnation porta sur une somme modeste — de l’ordre de six cent cinquante dollars canadiens, outre intérêts et frais — mais le principe est ce qui compte : la défense « c’est le bot qui s’est trompé » n’est pas une défense. Dans l’ordre juridique italien, la même affaire se jouerait entre l’art. 1218 et l’art. 2043 du Code civil italien, selon qu’un contrat existait ou non.

Le problème juridique sérieux n’est pas d’établir si quelqu’un répond — quelqu’un répond toujours — mais de gouverner à l’avance la répartition interne entre les acteurs de la chaîne. Les rôles sont au moins au nombre de trois et doivent être tenus distincts : celui qui utilise le système sous sa propre autorité dans l’exercice de son activité, c’est-à-dire le déployeur — position dans laquelle se trouve la quasi-totalité des entreprises et des cabinets professionnels ; celui qui met le système sur le marché ou le met en service sous son propre nom ou sa propre marque, c’est-à-dire le fournisseur — qualification qui peut se déclencher par inadvertance même pour la petite entreprise qui distribue sous sa marque un logiciel développé par des tiers ; et celui qui le produit, position que le droit européen est en train de redéfinir en ce moment même. Le régime aujourd’hui en vigueur sur le produit défectueux, construit sur les art. 114 et 115 du Code de la consommation italien, repose sur une notion de produit ancrée dans le bien meuble, dans laquelle le logiciel fourni de manière autonome — comme service en ligne ou dans le cloud — n’entre pas de façon incontestée. La directive (UE) 2024/2853 ferme cette brèche, en incluant expressément le logiciel dans la notion de produit quel que soit le mode de fourniture, en introduisant des présomptions de défectuosité et de lien de causalité en faveur de la victime dans les cas de complexité technique excessive, et en établissant que le fabricant n’est pas exonéré lorsque le défaut dépend du logiciel ou de l’absence des mises à jour de sécurité nécessaires, tant que le produit reste sous son contrôle. Le délai de transposition est le 9 décembre 2026 et la directive s’applique aux produits mis sur le marché ou mis en service après cette date. Deux précisions s’imposent toutefois : au 1er septembre 2026, le décret législatif italien de transposition n’a pas été publié à la Gazzetta Ufficiale — la délégation a été conférée par la loi de délégation européenne de mars 2026 et le projet est à l’examen des Chambres —, et même après le 9 décembre 2026 les deux régimes coexisteront pendant des années, distingués selon la date de mise sur le marché du produit. Qui conçoit aujourd’hui contrats et couvertures d’assurance doit donc raisonner sur le texte européen, sans attendre la Gazzetta.

Sur deux constructions très citées, il convient d’être net, car leur circulation comme droit en vigueur est source d’erreurs. Que l’« agent logiciel » puisse être traité comme un préposé électronique, avec application par analogie de l’art. 2049 du Code civil italien au commettant, est une thèse doctrinale soutenue par des auteurs autorisés mais dépourvue, en l’état, de consécration normative ; ce qui est norme, c’est l’imputation à l’employeur ou au commettant du fait illicite des personnes insérées dans son organisation, et donc du salarié qui fait mauvais usage d’un système d’IA. De même, que l’emploi de systèmes d’IA constitue en soi une « activité dangereuse » au sens de l’art. 2050 du Code civil italien est une thèse controversée, défendue pour les usages à fort impact et niée par une autre partie de la doctrine au motif que la dangerosité doit être établie au cas concret : pour une entreprise ordinaire, ce n’est ni une menace à craindre ni une protection sur laquelle compter. Il faut enfin boucler la boucle sur le professionnel, car la règle vaut d’abord pour celui qui l’enseigne : l’art. 13, alinéa 2, de la loi du 23 septembre 2025, n° 132 prescrit que les informations relatives aux systèmes d’intelligence artificielle utilisés par le professionnel soient communiquées au destinataire de la prestation intellectuelle dans un langage clair, simple et exhaustif, en protection du lien de confiance ; la norme ne prévoit ni forme imposée ni sanction propre, mais sa violation s’apprécie sur le plan déontologique et sur celui de l’inexécution contractuelle. C’est exactement ce que fait ce parcours lorsqu’il déclare au client quels outils le Cabinet emploie et pour quoi faire. Le principe doit toutefois être énoncé dans les deux sens, et c’est le risque de réciprocité que ce chapitre doit rendre explicite : la même règle qui protège l’entreprise quand elle est utilisatrice de services l’expose quand c’est elle qui se sert de l’IA envers ses propres clients.

Pourquoi il est utile de le savoir

• Vis-à-vis du client, la charge de la preuve joue contre l’entreprise : démontrer que l’erreur vient de l’outil ne suffit pas, car le choix, la configuration et la surveillance de l’outil sont les siens.
• La solidarité avec présomption de fautes égales (art. 2055 du Code civil italien) rend décisif le contrat avec le fournisseur : sans clauses expresses de garantie et de répartition, le risque résiduel se distribue par présomption de parité.
• La traçabilité des choix techniques et organisationnels — instructions opérationnelles, contrôles humains, formation, conservation des journaux — n’est pas une formalité : au contentieux, c’est la documentation qui distingue la diligence de la faute.

Dire qu’un cabinet professionnel « utilise l’intelligence artificielle » ne signifie presque rien, car sous la même formule cohabitent des pratiques très différentes : celui qui se borne à demander un résumé et celui qui confie à l’outil la substance de la réponse au client. Mieux vaut donc être précis sur la méthode plus que sur l’annonce. Au Cabinet, l’IA est employée comme outil de préparation : elle rassemble, ordonne, propose une première rédaction, signale ce qui manque. Pour les contenus techniques, le travail n’est pas confié à un unique outil générique, mais à plusieurs agents spécialisés par matière — le domaine fiscal, le domaine juridique, le domaine douanier — chacun réglé sur son langage et sur ses sources, dont les textes sont ensuite soumis à une révision croisée : celui qui a préparé le contenu n’est pas la même personne que celle qui le relit. C’est une technique ordinaire dans les cabinets, appliquée à un matériau nouveau : le double regard n’a pas été inventé pour l’IA, mais avec l’IA il devient indispensable, car l’outil produit des textes bien écrits même quand ils sont faux, et un texte bien écrit fait baisser la garde du lecteur.

La règle qui soutient toute la méthode est unique : l’IA prépare, le professionnel signe. Les autres en découlent. Chaque référence normative destinée à être publiée est confrontée aux sources primaires — le texte de la norme tel qu’il résulte des bases de données officielles italiennes et européennes — avant que le contenu ne sorte : on ne se fie ni à la mémoire de l’outil ni à une source de seconde main, car les normes changent et un outil entraîné sur des matériaux du passé peut restituer avec assurance un texte qui n’est plus en vigueur. Les contenus en langue étrangère passent par une révision linguistique dédiée, car une traduction automatique correcte sur le plan grammatical peut être imprécise sur le plan technique, et en matière fiscale la différence entre deux termes voisins est souvent la différence entre deux institutions distinctes. Les données identifiantes des clients restent hors des outils externes. Et rien ne part vers un client ou vers une administration sans qu’une personne du Cabinet l’ait lu et approuvé. Il faut toutefois dire avec la même clarté qu’aucune de ces règles ne rend le résultat infaillible : elles réduisent la probabilité de l’erreur et en rendent l’origine traçable, ce qui est ce que l’on peut raisonnablement exiger d’une méthode.

La raison pour laquelle ce chapitre figure dans un cours destiné aussi aux clients est double. La première est la transparence : celui qui confie à un cabinet sa comptabilité, ses déclarations et ses contrats a le droit de savoir comment ce travail est effectué, et la réponse « avec l’IA », sans autre précision, n’est pas une réponse. La seconde est la transférabilité. Les cinq règles ne sont pas un protocole construit sur mesure pour un cabinet professionnel : ce sont des principes de bon sens organisationnel qu’une petite entreprise peut adopter à sa propre échelle, avec son papier à en-tête et ses propres processus. Celui qui rédige des devis, des réponses à des réclamations, des textes pour le site ou des communications au personnel se trouve exactement dans la même situation — un outil qui écrit bien et ne sait pas ce qui est vrai — et a besoin des mêmes garde-fous. La différence entre un usage mûr et un usage improvisé de l’IA ne tient pas à la qualité de l’outil, mais à l’existence d’une méthode écrite et au fait que quelqu’un l’applique même quand il est pressé.

Pourquoi il est utile de le savoir

• Demander à son conseil comment il utilise l’IA est une question légitime et utile : la réponse qui compte n’est pas quel outil il emploie, mais qui relit, ce qui est vérifié et quelles données ne sortent jamais du cabinet.
• La révision croisée — celui qui relit n’est pas celui qui a préparé le texte — est le garde-fou le plus économique et le plus efficace, parce qu’elle intercepte précisément l’erreur que l’IA produit le mieux : celle qui est bien écrite.
• Les cinq règles du Cabinet sont reproductibles en entreprise sans investissements : séparation par matière, vérification des sources, relecture par une autre personne, aucune donnée confidentielle dans les outils externes, approbation humaine avant l’envoi.

L’adoption de l’IA dans une petite ou moyenne entreprise échoue presque toujours de la même manière : on achète un outil, on le distribue aux personnes, on attend qu’il se passe quelque chose. Il ne se passe rien, ou bien il se passe quelque chose de désordonné — quelqu’un l’utilise beaucoup et bien, quelqu’un pas du tout, personne ne sait ce qui a été produit avec quel outil — et au bout de quelques mois le projet est rangé avec la conclusion que « pour nous, ce n’était pas utile ». Le défaut de cadrage se situe à l’origine : on est parti de l’outil au lieu du processus. La bonne question n’est pas quelle technologie adopter, mais quelle activité de sa journée de travail est répétitive, textuelle, fréquente et à faible risque. Une fois cette activité identifiée, le choix de l’outil devient presque secondaire, parce que le critère est clair et le résultat mesurable. Avant cela, toute évaluation est abstraite, et les évaluations abstraites en entreprise se règlent en achetant la solution dont on a le plus entendu parler.

Le coût d’un projet d’IA n’est pas la licence : c’est le temps de cadrage et de contrôle, et ce temps doit être budgété avant de commencer. Bien cadrer une tâche répétitive exige de l’écrire de manière explicite — ce qu’elle doit produire, sous quelle forme, avec quelles contraintes, ce qu’elle ne doit jamais faire — et ce travail d’explicitation est la partie la plus laborieuse, parce qu’il oblige à dire à voix haute comment on travaille vraiment, ce qui, dans beaucoup d’entreprises, n’a jamais été écrit nulle part. Il faut ensuite décider qui contrôle le résultat et avec quelle attention, car un contrôle qui coûte autant que refaire le travail annule le bénéfice. Le temps passé ici ne se récupère que sur les volumes : c’est la raison pour laquelle le premier cas d’usage doit être cherché parmi les choses que l’on fait chaque semaine, pas parmi celles que l’on fait une fois par an, aussi ennuyeuses soient-elles. Toutefois, même un projet qui ne produit pas d’économie mesurable peut valoir la peine, s’il sert à construire une compétence interne sur un usage appelé à devenir ordinaire : à condition de le déclarer dès le départ, au lieu de se raconter un retour économique qui n’existe pas.

L’approche qui tient le mieux dans les entreprises de taille réduite est graduelle et réversible : un processus à la fois, avec une photographie de la situation de départ — combien d’heures, combien de personnes, combien d’erreurs ou de reprises — et une vérification à quelques mois de distance sur les mêmes indicateurs. Cela sert à deux choses. La première est de comprendre si le bénéfice existe vraiment, au lieu de s’en remettre à l’impression de celui qui a promu le projet, toujours favorable. La seconde, plus importante, est de pouvoir s’arrêter : un projet qui ne fonctionne pas doit être clos sans que cela devienne la défaite personnelle de quelqu’un, et ce n’est possible que si l’on a dit au départ qu’il s’agissait d’un essai avec des critères de sortie. Celui qui étend l’usage à toute l’entreprise avant d’avoir mesuré le premier processus n’accélère pas : il ne fait que rendre plus coûteux l’éventuel pas en arrière. La prudence, ici, n’est pas de la défiance envers la technologie, mais la même précaution que l’on prendrait pour tout autre investissement organisationnel aux effets incertains.

Pourquoi il est utile de le savoir

• Le critère de choix du premier cas d’usage est quadruple — répétitif, textuel, à fort volume, à faible risque — et il s’applique avant de regarder le moindre outil.
• Le désordre des données de l’entreprise est la cause d’échec la plus fréquente et en même temps la moins attribuée à l’IA : remettre en ordre archives et documents produit de la valeur même si le projet ne se poursuit pas.
• Fixer au départ deux ou trois indicateurs mesurables et une date de vérification est ce qui permet de s’arrêter sans coûts de réputation internes, et donc ce qui rend l’essai acceptable.

Les règles d’usage de l’IA sont presque toujours écrites après le premier incident : un document confidentiel parti dans un outil externe, une réponse à un client contenant une référence inexistante, une communication expédiée sans que personne ne l’ait relue. C’est le pire moment pour les écrire, car la réaction à chaud produit des interdictions généralisées qui cessent d’être appliquées en quelques semaines. La politique sert avant, et elle sert surtout à rendre explicites des décisions que chacun, sinon, prend pour son propre compte : quels outils peuvent être utilisés pour le travail et lesquels non, si le compte personnel est admis, ce que l’on peut charger et ce que l’on ne peut pas. En l’absence d’indications, les personnes ne cessent pas d’utiliser l’IA : elles l’utilisent en cachette, avec des outils choisis par elles, et l’entreprise perd toute possibilité de savoir ce qui a été produit, comment et avec quelles données. Le premier effet d’une politique n’est pas de limiter l’usage, mais de le faire émerger.

Une politique utile est courte, concrète et nominative : elle dit ce que l’on peut faire, avec quels outils, avec quelles données, et surtout elle dit qui contrôle quoi avant qu’un contenu ne sorte de l’entreprise. Le point du contrôle est celui sur lequel se joue son efficacité, et il doit être écrit de sorte qu’à chaque type de production corresponde une personne : les communications aux clients, les textes publiés, les documents destinés aux administrations et organismes, les supports internes n’ont pas le même risque et ne méritent pas la même intensité de vérification. Il faut prévoir à côté un canal simple pour signaler les erreurs — à qui s’adresser, sous quelle forme, avec quelles conséquences — car un signalement qui expose son auteur n’arrive jamais, et les erreurs que personne ne signale se répètent. Il faut enfin indiquer une date de révision : les outils changent vite et une politique restée deux ans en arrière énumère des interdictions sur des services qui n’existent plus et se tait sur ceux que les personnes utilisent vraiment. Toutefois, aucune de ces dispositions ne fonctionne si le document reste dans un dossier partagé : la politique vaut ce que vaut la formation qui l’accompagne, et c’est elle qui la transforme d’une formalité en une pratique.

Il reste un dernier argument, qui mérite d’être explicité parce que c’est généralement celui qui convainc le décideur. La politique protège deux fois. La première, à titre préventif : la plupart des incidents concernant l’IA en entreprise ne naissent pas de la mauvaise foi mais de l’absence d’instructions, et une règle écrite les évite à un coût à peu près nul. La seconde, a posteriori : si quelque chose tourne mal — une donnée sortie là où elle ne devait pas, un contenu erroné parvenu à un tiers — l’entreprise qui peut montrer des règles écrites, adoptées avant les faits, communiquées au personnel et accompagnées de formation, se trouve dans une position radicalement différente de celle qui n’a rien à produire. Ce n’est pas une garantie d’exonération de responsabilité, et il ne faut pas la présenter ainsi : c’est la démonstration documentaire d’une diligence organisationnelle, qui pèse toujours dans les appréciations ultérieures. La différence entre les deux situations ne tient pas au fait — qui est identique — mais à la capacité de démontrer que l’entreprise avait fait ce qu’il était raisonnable de faire.

Pourquoi il est utile de le savoir

• Une politique de quelques pages, avec des exemples tirés de l’activité réelle de l’entreprise, produit plus d’effets qu’un document long et générique : elle doit être écrite avant le premier incident, pas après.
• Le noyau minimal est toujours le même : outils approuvés, données interdites, responsable du contrôle pour chaque type de production, canal de signalement des erreurs, formation du personnel, date de révision.
• La politique prévient les erreurs et, si quelque chose tourne mal, documente la diligence de l’entreprise : deux fonctions distinctes, toutes deux perdues si le document n’est pas communiqué et expliqué à ceux qui travaillent.

Clore un parcours sur l’IA en parlant de personnes n’est pas un retour rhétorique à l’humanisme : c’est la conséquence pratique de tout ce qui précède. Un outil qui écrit avec aisance, répond vite et ne montre jamais d’hésitation produit un effet psychologique précis sur celui qui l’utilise — l’impression que la question est réglée. Dans bien des cas elle l’est ; dans certains non, et ce sont précisément ceux où la réponse paraissait la plus sûre. D’où la nécessité de distinguer nettement deux manières de travailler qui, vues de l’extérieur, se ressemblent. Se faire aider à décider signifie utiliser l’outil pour voir davantage : rassembler ce qui est dispersé, comparer des alternatives, faire émerger l’objection que l’on n’avait pas considérée. Laisser décider signifie au contraire adopter le résultat parce qu’il est arrivé, sans avoir les éléments pour le contester. La seconde modalité est rarement choisie : on y glisse, par les volumes, par les délais serrés, par la confiance accumulée. Et c’est précisément pour cela qu’il faut la nommer avant qu’elle n’advienne, et non la reconnaître après.

Certaines décisions ne se délèguent pas, et non parce que la machine se tromperait plus que l’homme, mais parce que celui qui les subit a droit à un interlocuteur qui réponde. Ce sont les décisions qui touchent des personnes — qui est embauché, qui est évalué, à qui l’on accorde une confiance économique — et celles dont on ne revient pas. Un algorithme peut classer cent candidatures selon un critère, et même bien le faire ; il ne peut pas assumer le fait qu’une personne n’ait pas été appelée, ni lui en expliquer la raison de manière vérifiable et contestable. Il en va de même pour le crédit, pour les conditions appliquées à un client, pour une mesure à l’égard d’un salarié. Le critère pratique à retenir est double : se demander si quelqu’un sera fondé à demander « pourquoi », et se demander si l’erreur sera corrigible demain. Si la première réponse est oui ou la seconde est non, la décision reste à une personne, qui peut utiliser tous les éléments préparés par l’outil mais ne peut pas se cacher derrière eux. Toutefois, cette ligne ne se trace pas une fois pour toutes : elle change avec l’expérience, avec la qualité des données et avec le type d’activité, et elle doit être réexaminée périodiquement au lieu d’être héritée.

Reste la question la plus difficile, qui relève de l’habitude et non de la règle. Relire coûte un effort, et ce coût se ressent chaque jour tandis que le bénéfice se voit une fois par an, quand une erreur est interceptée. C’est une asymétrie qu’aucune procédure n’élimine tout à fait : on peut seulement la rendre moins pesante, en concentrant le contrôle là où le dommage serait le plus grand au lieu de le répartir uniformément sur tout, et en acceptant de contrôler moins ce qui est sans importance. Le sens de ce parcours, s’il en a un, tient en une formule simple : utiliser l’IA beaucoup et lui déléguer peu. Beaucoup, parce que le temps libéré du travail répétitif est du temps qui redevient disponible pour ce qui mérite l’attention. Peu, parce que la responsabilité de ce que l’on communique, signe et décide reste là où elle a toujours été — sur les personnes — et qu’aucune évolution des outils ne la déplacera ailleurs. Le professionnel qui signe ne garantit pas de ne jamais se tromper : il garantit que derrière ce document il y a quelqu’un qui l’a lu, l’a compris et en répond.

Pourquoi il est utile de le savoir

• La frontière entre assistance et délégation n’est pas technique mais organisationnelle : elle dépend du fait que celui qui approuve dispose de suffisamment de temps, d’informations et d’autorité pour refuser le résultat proposé.
• Deux questions suffisent à situer une décision : quelqu’un sera-t-il fondé à demander « pourquoi », et l’erreur sera-t-elle corrigible ? Si la réponse est oui à la première ou non à la seconde, c’est une personne qui décide.
• L’attention baisse sous l’effet de la répétition, non de la négligence : mieux vaut concentrer le contrôle là où le dommage potentiel est le plus grand, plutôt que d’exiger une vigilance uniforme qui ne tient pas dans la durée.