Nous écrivons souvent la même phrase : l’IA prépare le travail, la décision reste chez vous. Ce n’est pas une formule de précaution pour finir une page. C’est une règle de conception. Elle dit ce que nous acceptons de confier à un modèle, et ce que nous refusons de lui laisser conclure tout seul. Voici comment nous la mettons en pratique, dans les automatisations, les outils métier, et les usages du quotidien.
Préparer, ce n’est pas décider
Un modèle de langage, un outil de transcription, un classement automatique, savent produire une proposition : un résumé, une catégorie, une réponse rédigée, une liste de champs extraits d’un texte. C’est précieux quand la tâche se répète, et quand une personne peut relire vite. Ce n’est pas une décision.
Décider, dans notre vocabulaire, c’est engager une conséquence : envoyer un message à un client, modifier un droit, valider une facture, publier un contenu, changer l’étape d’une affaire sensible, confier un document à un tiers. Si le modèle se trompe à cette étape, le coût n’est plus une reformulation. C’est une action dans le monde réel, parfois difficile à retirer.
Nous plaçons donc la frontière le plus tôt possible dans le parcours. L’IA peut remplir un brouillon. Elle peut suggérer une étiquette. Elle peut proposer un score. Un humain confirme, ou corrige, avant que l’action parte. Quand la confirmation n’existe pas, ce n’est plus de l’assistance. C’est une délégation, et elle doit être volontaire, écrite, rare.
Ce que nous confions volontiers à un modèle
La rédaction d’une première version, à partir d’un brief clair, est un bon candidat. La personne qui connaît le sujet relit, coupe, corrige le ton. Le modèle a fait gagner le temps de la page blanche, pas celui du jugement.
Le résumé d’un texte long, le classement d’une demande, l’extraction de champs déjà présents dans un document, vont dans le même sens. Encore faut-il que le texte puisse être envoyé au service utilisé, et que le résultat soit vérifiable. Un résumé que personne ne compare au document d’origine n’est plus un appui. C’est une source nouvelle, non contrôlée.
La préparation d’un rendez-vous, d’une réponse type, d’une liste de points à vérifier, aussi, à condition de rester dans un rôle d’aide. Nous l’utilisons dans des workflows n8n, dans des outils, dans des usages internes. Le schéma reste le même : le modèle produit, l’équipe dispose.
Certaines tâches visuelles — proposer une image à partir d’une description, décliner un format — peuvent entrer dans cette liste, avec la même relecture. Une image générée n’est pas une photographie d’un fait. On ne la présente pas comme telle.
Ce que nous gardons, systématiquement
Les accès et les droits. Un modèle ne crée pas un compte administrateur, n’ouvre pas un dossier confidentiel, ne partage pas un lien large, sans une action humaine explicite. Les automatisations qui touchent aux identités s’arrêtent avant, ou demandent une validation.
Les envois vers l’extérieur. Un courriel à un client, un message sur un canal public, une publication, passent par une relecture. On peut préparer le texte. On n’appuie pas sur « envoyer » par défaut. Les exceptions, s’il y en a, sont étroites, documentées, et réversibles autant que possible.
Les documents dont on ne maîtrise pas le contenu. Avant d’envoyer un fichier à un service d’IA, on se demande s’il contient des données personnelles, des secrets, des pièces que le contrat du service ne couvre pas comme on le croit. S’il le faut, on retravaille le fichier, on le pseudonymise, ou on garde le traitement local, humain. Nous y reviendrons dans d’autres notes, outil par outil. Le principe, lui, ne dépend pas de l’outil.
Les chiffres et les faits que l’on n’a pas vérifiés. Un modèle peut inventer une référence, une date, un montant. Dans un article, un devis, une réponse à un client, nous ne laissons pas une assertion sans source. Si nous ne pouvons pas la vérifier, elle ne sort pas.
Dans les outils, la frontière doit être visible
Une phrase dans une charte ne suffit pas. Dans un workflow, on voit où le modèle intervient, et où il s’arrête. Dans une interface, le texte proposé n’est pas mélangé à un texte déjà validé, sans marque. La personne qui relit doit savoir ce qui vient d’être généré.
Les clés d’API, les quotas, les journaux, font partie de ce dispositif. Une clé trop permise, un budget sans limite, un historique que personne ne consulte, déplacent la frontière sans qu’on l’ait décidé. Nous avons déjà écrit qu’une alerte de budget ne suffit pas. Ici, c’est la même idée : l’outil doit rendre le recours au modèle conscient, pas furtif.
Quand nous ajoutons de l’IA à un produit ou à un projet client, nous posons ces questions dans le cadrage. Quel service, quelles données, quelle conservation, quelle validation humaine, que se passe-t-il en cas d’erreur ? Si l’une de ces réponses manque, on ne branche pas le nœud « pour voir ».
Un exemple, volontairement banal. Un formulaire interne arrive. Un modèle en tire un résumé et propose une catégorie. Un membre de l’équipe ouvre la fiche, corrige deux phrases, change éventuellement la catégorie, puis choisit d’informer un collègue. Le modèle a réduit le temps de lecture. Il n’a pas parlé au nom de l’organisation. Si, à l’inverse, le résumé partait automatiquement au client, la moindre invention, le moindre ton maladroit, deviendrait immédiatement un problème de relation, pas un problème de prompt.
Autre exemple, côté technique. Dans n8n, un nœud peut appeler un modèle pour extraire des champs d’un brief, puis un autre nœud peut créer une fiche. Entre les deux, nous plaçons souvent une condition, un canal de relecture, ou au minimum un état « à valider ». Créer une fiche interne, encore, peut se discuter. Envoyer un devis, déclencher un paiement, modifier une commande : ce n’est plus le même étage. La stack n’y change rien. Que l’on soit en PHP, en JavaScript ou dans un workflow, la décision reste un acte, pas une génération.
Nous appliquons aussi cette règle à nous-mêmes, quand nous écrivons, quand nous préparons une maquette, quand nous explorons une piste technique. L’outil accélère. Il n’a pas le dernier mot sur un fait, un engagement, ou une recommandation que nous signons. Si une information n’est pas vérifiable, elle n’entre pas dans un livrable. Cette discipline est un peu lente, le premier jour. Elle évite, ensuite, de défaire ce qu’un modèle aura affirmé trop vite.
Les équipes nous demandent parfois une politique « IA » d’une page. Nous préférons une liste courte, tenable : quels outils sont autorisés, pour quels types de contenus, avec quelle relecture, et ce qui est interdit sans discussion — typiquement l’envoi de pièces nominatives vers un service non prévu, ou la publication sans relecture. Une politique trop longue, que personne ne relie au travail réel, ne protège personne. Une règle courte, rappelée dans les outils, a plus de chances de vivre.
Une règle simple, à tenir dans la durée
Les outils changent. Les modèles aussi. La règle, elle, peut rester. L’IA prépare. Elle classe, elle rédige, elle transcrit, elle propose. La décision, surtout lorsqu’elle a une conséquence vers une personne ou un système, reste chez vous — chez l’équipe, chez le responsable du traitement, chez celui qui signe.
Si vous voulez poser cette frontière dans un projet d’automatisation, de site ou d’outil métier, nous pouvons l’écrire avec vous dès le premier échange. La page contact et notre agenda sont là pour ça. On part du travail réel, pas d’une démonstration de modèle.