Publié le 4 octobre 2026 - md22
Un utilitaire IA confie à l'IA un accès direct à ses tables, sans code écrit ni contrôlé par un humain. Un utilitaire avec IA humaine fait travailler l'IA au-dessus d'un socle de code éprouvé, sur les seuls éléments que ce code lui transmet, sans jamais lui ouvrir la base.
Utilitaire IA ou utilitaire avec IA : où passe la vraie ligne de partage ?
Deux modèles coexistent sous un même vocabulaire. Dans l'utilitaire IA, l'IA est le coeur du produit et elle a la main sur les données. Dans l'utilitaire avec IA, le coeur du produit est un socle de code éprouvé : l'IA travaille au-dessus, sans jamais accéder à la base.
Les outils qui surfent sur la vague actuelle sont jeunes. Contrairement à DionySols, lancé en 2017, ils ne reposent pas sur un socle de code qui réglemente les écritures en table et la restitution des données. Ils se présentent eux-mêmes comme des « utilitaires IA » : c'est leur propre discours, et il dit où se trouve le centre de gravité du produit.
Le sujet ne concerne pas que les grands groupes. Une enquête Microsoft France / YouGov menée en janvier 2026 auprès de 657 cadres et dirigeants d'entreprises privées françaises relève que l'usage hebdomadaire de l'IA générative atteint 55 % dans les très petites entreprises, contre 69 % dans les grands groupes. La même enquête indique que 61 % des utilisateurs de l'IA en entreprise passent par des comptes personnels au moins une fois par semaine, dont 38 % chaque jour, et que plus de sept cadres sur dix n'ont pas été formés à l'IA.
Une IA ne décide de rien d'elle-même : elle agit avec les accès qu'on lui a donnés. Le danger ne vient donc pas de l'IA en soi, mais de l'utilitaire qui lui ouvre un accès direct aux tables.
La vraie ligne de partage tient en une question : qui écrit le code qui touche aux données, l'humain ou l'IA ?
IA pure et IA humaine : deux définitions pour ne plus les confondre
L'IA pure est une IA qui agit comme bon lui semble à partir d'une simple question, parce que l'utilitaire lui en ouvre l'accès. Elle intervient et accède seule aux tables, en lecture comme en écriture, directement. Elle n'agit pas pour autant « sans code » : elle génère elle-même ses requêtes. Ce qui manque, c'est un code écrit et contrôlé par un humain entre la question et la donnée.
L'IA humaine est une IA cadrée en amont par du code écrit et maîtrisé par l'humain. Elle obéit à des scripts précis qui limitent ses actions, et elle n'accède jamais à la base : le contrôle des données reste entier. Son objectif est de simplifier encore et toujours, de faire gagner du temps et de proposer des analyses plus poussées.
L'IA humaine ne se confond pas avec la validation humaine de chaque résultat, ce que l'on appelle le « human in the loop ». Ici, l'humain intervient avant : il écrit et maîtrise le code qui encadre l'IA. Il ne valide pas chaque réponse. C'est le code qui fixe, une fois pour toutes, ce que l'IA peut voir et faire.
Deux principes qui tiennent l'IA à distance de la base
- La minimisation : l'utilitaire transmet à l'IA uniquement les éléments de la base strictement nécessaires au travail demandé.
- Le cloisonnement : la transmission se fait par un fichier reconstitué, qui coupe tout lien entre l'IA et la base de données. L'IA voit le contenu de ce fichier ; elle n'a jamais accès à la base.
Le code décide donc de ce que l'IA voit, et l'IA n'a jamais la main sur la base.
IA pure et IA humaine, critère par critère
| Critère | IA pure | IA humaine |
|---|---|---|
| Qui écrit le code qui touche aux données | L'IA, qui génère ses propres requêtes | L'humain, en amont |
| Accès à la base | Direct, en lecture et en écriture | Aucun : l'IA n'accède jamais à la base |
| Écriture en table | Possible, sans code contrôlé par un humain | Impossible pour l'IA |
| Données vues par l'IA | Ce que l'IA décide d'interroger | Les seuls éléments nécessaires, dans un fichier reconstitué |
| Rôle de l'humain | Il pose la question | Il écrit et maîtrise le code qui cadre l'IA |
| Origine du risque | L'accès ouvert par l'utilitaire | Circonscrite par le code |
Utilitaires IA : efficaces pour démarrer, pas pour piloter sa rentabilité
Les utilitaires IA ont de vrais points forts : une mise en place rapide, l'interrogation en langage naturel, et une bonne adaptation à l'exploration, au brouillon et à la question ponctuelle. C'est ce qui les rend attirants.
Pour une TPE qui pilote sa rentabilité, quatre limites apparaissent.
- La reproductibilité. Une même question peut donner deux réponses différentes. Un calcul de marge qui varie d'un jour à l'autre ne sert pas à piloter.
- La fiabilité des chiffres. Une IA peut produire un résultat faux mais plausible, sans signal d'erreur. Sans règles de calcul figées dans le code, rien ne l'arrête.
- Les règles métier. Le coût matière, les pertes, les unités et les fiches techniques ne s'improvisent pas à chaque question. Ces règles s'écrivent une fois, dans le code.
- L'intégrité des données. Avec un accès en écriture, une erreur d'interprétation ne reste pas une mauvaise réponse. Elle devient une donnée corrompue dans la base, qui fausse toutes les analyses suivantes.
Ce raisonnement découle du fonctionnement même de ces outils. Il ne repose sur aucune étude mesurée de leur efficacité : nous n'en avons trouvé aucune.
Un utilitaire IA confie à l'IA ce que le code devrait garantir.
Ce que disent les sources de 2026 sur l'accès des IA aux données
Quatre sources publiées en 2026 forment une chaîne : OWASP nomme la cause, l'incident PocketOS l'illustre, IBM en mesure la conséquence, Gartner annonce le retour de bâton.
La cause : l'agentivité excessive, selon OWASP
L'édition 2026 du Top 10 OWASP des risques des applications LLM, publiée le 4 août 2026, fait passer l'« agentivité excessive » de la sixième à la troisième place. C'est la plus forte progression du classement. Le terme désigne le fait d'accorder à une IA plus de fonctions, de permissions ou d'autonomie que nécessaire. Le classement s'appuie sur plus de 7 700 incidents recensés dans des bases publiques de vulnérabilités et une base de dommages liés à l'IA.
OWASP identifie trois causes : des fonctions superflues, des permissions trop larges, et une autonomie sans confirmation humaine sur les opérations à fort impact. Ses recommandations : ne donner à l'IA que les accès strictement nécessaires, en lecture seule sur la base quand c'est possible, et imposer ces limites au niveau de l'infrastructure, pas dans la logique de l'IA.
L'illustration : l'incident PocketOS d'avril 2026
Un agent IA de codage, chargé d'un correctif dans un environnement de test, a supprimé en un seul appel API, en neuf secondes, la base de données de production de la petite société PocketOS et toutes ses sauvegardes. La société et ses clients ont été bloqués pendant 30 heures.
Les analyses désignent trois causes structurelles : des tokens API trop permissifs, l'absence de séparation stricte entre test et production, et l'absence de validation pour les opérations critiques. L'agent reposait sur le modèle d'un grand éditeur du marché, mais ce n'est pas le modèle qui est en cause : c'est l'accès qui lui avait été accordé. L'agent est le dernier maillon, pas la cause première. C'est un cas isolé, pas une statistique ; il montre jusqu'où peut mener un accès direct aux tables.
La conséquence : les chiffres d'IBM
Le Cost of a Data Breach Report 2026 d'IBM, publié le 29 juillet 2026 avec le Ponemon Institute, apporte quatre constats. Parmi les organisations victimes d'une violation liée à l'IA, 92 % n'avaient pas de contrôles d'accès IA adaptés. 68 % n'avaient pas de politique de gouvernance de l'IA, contre 63 % l'année précédente. Les incidents de shadow AI, c'est-à-dire les outils d'IA utilisés par les salariés sans validation de l'entreprise, sont passés de 20 % en 2025 à 43 %. Enfin, les violations liées à l'IA représentent 21 % de l'ensemble des violations, contre 13 % un an plus tôt.
Ces chiffres portent sur des organisations de toutes tailles, à l'échelle mondiale. Ce ne sont pas des chiffres propres aux TPE françaises.
La suite : la prédiction de Gartner
Dans un communiqué du 26 mai 2026, Gartner prévoit que, d'ici 2027, 40 % des entreprises rétrograderont ou retireront leurs agents IA autonomes, à cause de failles de gouvernance découvertes seulement après des incidents en production. C'est une prédiction, pas une mesure. Au premier niveau de son échelle d'autonomie, le plus prudent, Gartner limite l'agent à un accès en lecture seule à des sources de données définies.
L'IA humaine va plus loin que ce premier niveau. En lecture seule, l'IA interroge encore la base : elle choisit ce qu'elle lit, ce qu'elle extrait et ce qu'elle analyse. Dans l'IA humaine, l'IA ne lit rien et n'extrait rien. C'est le code qui sélectionne les données, les extrait et les lui remet dans un fichier reconstitué. L'IA analyse ce qu'on lui donne, rien de plus.
La chaîne de preuve 2026 en un tableau
| Maillon | Source | Ce qu'elle établit |
|---|---|---|
| La cause | OWASP, Top 10 LLM 2026 | L'agentivité excessive passe de la sixième à la troisième place des risques |
| L'illustration | Incident PocketOS, avril 2026 | Une base de production et ses sauvegardes supprimées en neuf secondes |
| La conséquence | IBM, Cost of a Data Breach Report 2026 | 92 % des organisations touchées n'avaient pas de contrôles d'accès IA adaptés |
| La prédiction | Gartner, communiqué du 26 mai 2026 | 40 % des entreprises rétrograderont ou retireront leurs agents IA autonomes d'ici 2027 |
Les recommandations convergent avec le principe de l'IA humaine, qui les pousse un cran plus loin : donner à l'IA les seuls accès strictement nécessaires, imposer ces limites dans l'infrastructure plutôt que dans la logique de l'IA, et ne pas même la laisser lire la base.
Sources
- OWASP, Top 10 LLM 2026 : HackerDNA, ReversingLabs, A10 Networks
- Incident PocketOS : La Revue du Digital, Hardware Cooking
- IBM, Cost of a Data Breach Report 2026 : IBM, Baker Donelson
- Gartner, communiqué du 26 mai 2026 : Gartner
- Microsoft France / YouGov, enquête de janvier 2026 : Microsoft
DionySols et DySiarc : une IA humaine posée sur un socle de code éprouvé
DionySols est un utilitaire web de pilotage de la rentabilité pour les restaurants et les métiers de bouche : coûts matière, marges, prix de revient. Il a été lancé le 10 avril 2017 et repose sur un socle de code de plus de neuf ans, antérieur à la vague IA. Son IA humaine complète les fonctions existantes : elle travaille au-dessus de ce socle, sur les seuls éléments que le code lui transmet.
DySiarc poursuit deux objectifs : simplifier encore et toujours DionySols pour les restaurants et les métiers de bouche, et permettre à toutes les autres professions de piloter et suivre leurs coûts matière. Pour le détail de son fonctionnement, voyez comment DySiarc lit et analyse les factures fournisseurs.
Deux outils qui travaillent ensemble sans jamais écrire l'un chez l'autre
- DySiarc constitue la mercuriale du client à partir de ses factures fournisseurs.
- DySiarc ne réécrit rien dans DionySols.
- DionySols lit les données de DySiarc par API et corrige ses calculs avec son propre code natif.
- Les prix d'achat sont mis à jour au fil des factures, et DionySols recalcule instantanément les marges et les prix de revient. Le dirigeant n'a aucune saisie à faire.
Ce fonctionnement démontre trois choses.
- Aucune IA n'écrit dans les tables, même entre les deux outils. DySiarc fournit les données, et c'est le code natif de DionySols qui recalcule. Ce cloisonnement distingue un socle éprouvé d'un utilitaire qui ouvre ses tables à l'IA.
- Simplifier n'oblige pas à lâcher le contrôle. DySiarc élargit l'usage sans ouvrir la base à l'IA.
- L'audience s'élargit au-delà des métiers de bouche, à toute TPE qui achète de la matière.
La sécurité et l'efficacité ne sont pas deux sujets distincts : toutes deux découlent du socle. DionySols fait travailler l'IA au-dessus d'un terrain déjà fiable.
Glossaire
- IA pure
- IA qui accède seule aux tables d'une base, en lecture et en écriture, à partir d'une simple question, sans code écrit ni contrôlé par un humain.
- IA humaine
- IA cadrée en amont par du code écrit et maîtrisé par l'humain, qui obéit à des scripts précis et n'accède jamais à la base.
- Minimisation
- Principe selon lequel l'utilitaire ne transmet à l'IA que les éléments de la base strictement nécessaires au travail demandé.
- Cloisonnement
- Transmission des éléments à l'IA par un fichier reconstitué, qui coupe tout lien entre l'IA et la base de données.
- Agentivité excessive
- Fait d'accorder à une IA plus de fonctions, de permissions ou d'autonomie que nécessaire. Troisième risque du Top 10 OWASP des applications LLM 2026.
Questions fréquentes sur l'IA humaine et l'IA pure
Un restaurateur peut-il utiliser un utilitaire IA pour calculer sa marge ?
Pour explorer une question ponctuelle, oui. Pour piloter, la marge doit être reproductible : les règles de calcul du coût matière, des pertes et des unités doivent être figées dans le code. Sans elles, une même question peut donner deux réponses différentes.
Qu'est-ce qui distingue une IA humaine d'une IA pure ?
La réponse à une seule question : qui écrit le code qui touche aux données. Dans l'IA pure, l'IA génère elle-même ses requêtes et accède directement aux tables. Dans l'IA humaine, l'humain écrit en amont le code qui cadre l'IA, et l'IA n'accède jamais à la base.
Un boucher qui utilise DySiarc ouvre-t-il sa base DionySols à l'IA ?
Non. DySiarc ne réécrit rien dans DionySols. DionySols lit les données de DySiarc par API et recalcule ses marges et ses prix de revient avec son propre code natif. Aucune IA n'écrit dans les tables, même entre les deux outils.
Pourquoi l'accès direct d'une IA aux tables est-il un risque ?
Parce qu'une erreur d'interprétation ne reste pas une mauvaise réponse : elle devient une donnée corrompue qui fausse toutes les analyses suivantes. OWASP classe l'agentivité excessive au troisième rang des risques des applications LLM en 2026, et recommande des limites imposées dans l'infrastructure.