Un assistant prépare un remboursement, ouvre le logiciel de facturation et clique sur « valider ». Le client reçoit son argent. Puis un salarié découvre que la demande était frauduleuse. Qui doit répondre de l’erreur : l’éditeur du modèle, l’intégrateur, le responsable métier ou l’entreprise qui lui a donné accès au compte ? Avec les agents IA, la question n’est plus seulement de savoir si une réponse est juste, mais qui autorise ses conséquences. Ce scénario illustre le chantier qui attend les organisations à l’horizon de septembre 2026.
Cette analyse s’appuie sur des évolutions documentées jusqu’en 2024 ; les développements envisagés pour septembre 2026 relèvent de la prospective. Une distinction essentielle dans un secteur où les démonstrations spectaculaires précèdent souvent les preuves de fiabilité.
Du conseil à l’exécution : le vrai changement
Un chatbot classique produit du texte. Un agent associe un modèle à des outils : moteur de recherche, messagerie, base clients, terminal informatique ou interface de paiement. Il peut décomposer une demande, sélectionner une opération, examiner son résultat et poursuivre. L’autonomie reste variable : certains parcours sont très balisés, d’autres laissent au modèle davantage de latitude.
Cette trajectoire était déjà visible en 2023 avec les fonctions permettant aux modèles d’appeler des outils, les expérimentations AutoGPT et les assistants connectés aux applications d’entreprise. En 2024, les démonstrations d’agents de programmation ont prolongé cette promesse : passer de « voici comment faire » à « je m’en occupe ». Mais réussir une démonstration ne garantit ni robustesse en production ni maîtrise des exceptions.
Le gain potentiel est concret. Un service achats pourrait automatiser la collecte des devis et préparer une commande. Un support informatique pourrait diagnostiquer une panne puis restaurer un accès. Le risque change pourtant de nature : une mauvaise suggestion se discute ; une suppression de fichiers, une divulgation ou un virement peuvent produire leurs effets avant toute relecture.
Une responsabilité distribuée, pas dissoute
Dire que « l’IA a décidé » ne règle rien. Un agent n’est pas, du seul fait de son autonomie technique, un sujet juridique auquel transférer la faute. Selon le pays, le contrat et le dommage, plusieurs responsabilités peuvent se combiner : celle de l’entreprise utilisatrice, du fournisseur d’un composant, de l’intégrateur ou d’un prestataire chargé de l’exploitation.
Un cas canadien a fourni un avertissement dès 2024. Dans l’affaire Moffatt contre Air Canada, le tribunal civil de Colombie-Britannique a retenu la responsabilité de la compagnie pour des informations erronées données par son chatbot au sujet d’un tarif de deuil. Il ne s’agissait pas d’un agent exécutant une opération autonome. L’affaire rappelle néanmoins qu’une entreprise ne peut pas simplement présenter son interface automatisée comme étrangère à ses obligations envers ses clients.
Pour un agent, l’enquête devient plus complexe. Le modèle a-t-il mal interprété une consigne ? L’intégration lui donnait-elle trop de pouvoirs ? Une règle métier était-elle absente ? Le salarié disposait-il d’assez d’informations pour approuver ? Il faut distinguer la cause technique, la responsabilité juridique et la responsabilité opérationnelle. Elles ne désignent pas nécessairement le même acteur.
Les autorisations deviennent le premier garde-fou
Le piège serait d’attribuer à un agent les droits du salarié qu’il assiste. Un collaborateur peut légitimement consulter des dossiers sensibles, engager des dépenses et envoyer des courriels. Son assistant n’a pas besoin de cumuler toutes ces capacités pour classer des factures. Le principe du moindre privilège, ancien en cybersécurité, devient ici une condition élémentaire de déploiement.
Concrètement, chaque agent devrait disposer d’une identité technique distincte, de droits limités et, lorsque c’est possible, temporaires. Lire n’implique pas modifier ; préparer n’implique pas transmettre ; créer un bénéficiaire n’implique pas pouvoir le payer. Les limites financières, les destinataires autorisés et les interdictions doivent être contrôlés par le système d’exécution, pas seulement demandés dans une instruction au modèle.
- Actions réversibles : automatisation possible dans un périmètre défini, avec contrôle après exécution.
- Actions sensibles : approbation explicite avant envoi, publication ou modification importante.
- Actions critiques : séparation des fonctions, double validation ou exclusion de l’autonomie.
Autre menace : l’injection de consignes malveillantes dans un document ou une page consultée. Un agent chargé de résumer un courriel pourrait y rencontrer une instruction lui demandant d’exporter des fichiers. Ce contenu extérieur doit rester une donnée, non devenir une autorité. Les restrictions d’accès et le filtrage des sorties doivent limiter les dégâts même si le modèle se laisse tromper.
Superviser ne signifie pas cliquer sur « approuver »
La supervision humaine semble une réponse évidente. Elle peut pourtant devenir une fiction organisationnelle. Si un salarié reçoit des dizaines de demandes incompréhensibles, dans l’urgence, il risque de tout valider. L’humain reste alors dans la boucle sur le papier, mais n’exerce plus de contrôle réel.
Une validation utile présente l’action prévue, ses conséquences, les éléments qui la justifient et les incertitudes pertinentes. Pour un remboursement, cela signifie afficher le montant, le bénéficiaire, la règle applicable et les éventuelles anomalies. Le superviseur doit pouvoir refuser, corriger et interrompre le processus, sans être pénalisé pour avoir ralenti l’exécution.
La bonne question n’est donc pas « avons-nous une validation humaine ? », mais « une personne compétente peut-elle effectivement empêcher le dommage ? ». Cela suppose du temps, une formation et un pouvoir d’arbitrage. Pour septembre 2026, on peut anticiper que cette capacité réelle de contrôle deviendra un critère de choix plus important que le nombre de tâches promises.
Tracer les actes sans tout enregistrer
Après un incident, une conversation sauvegardée ne suffit pas. Il faut reconstituer les outils appelés, les paramètres transmis, les droits disponibles, les réponses reçues et les validations obtenues. La version du modèle, la configuration de l’agent et les règles applicables comptent également : un même objectif peut produire des parcours différents après une mise à jour.
Cette traçabilité ne nécessite pas d’exposer un supposé raisonnement interne exhaustif du modèle. Elle exige surtout des preuves observables de ses actes. Les journaux doivent être protégés contre l’altération, accessibles aux personnes habilitées et soumis à des durées de conservation proportionnées. Tout enregistrer sans discernement créerait un autre risque : accumuler des données personnelles, des secrets commerciaux ou des identifiants.
Le droit encadre, l’organisation doit suivre
Adopté en 2024, le règlement européen sur l’IA prévoit une application progressive, avec une échéance générale fixée au 2 août 2026 dans son calendrier initial et des exceptions. Il ne classe pas automatiquement tous les agents comme systèmes à haut risque : l’usage et les conditions prévues par le texte sont déterminants. Le RGPD, le droit des contrats et les règles sectorielles restent également pertinents. Aucun label d’« agent » n’efface ces obligations.
Et maintenant ? Le scénario crédible n’est pas une entreprise abandonnée à des logiciels souverains, mais une autonomie graduée, testée et révocable. Avant d’étendre un agent, les dirigeants devraient pouvoir répondre à trois questions : que peut-il engager, qui peut l’arrêter et quelles preuves restera-t-il demain ? La confiance viendra moins de son aisance à converser que de la solidité des limites qui l’entourent.
