Le 1er octobre, on a passé la journée à la Mêlée Numérique, à Toulouse, et on a suivi plusieurs sessions sur l’IA en entreprise. Des intervenants très différents, et pourtant les mêmes sujets sont revenus d’une salle à l’autre. Voici ce qu’on en retient chez Atecna !

Les sessions suivies :

Le shadow AI ne se règle pas en interdisant

Quand on interdit ChatGPT, les gens continuent de l’utiliser, simplement la DSI ne le voit plus. Le shadow AI, c’est-à-dire l’usage d’outils d’IA sans validation de la DSI, est revenu dans les quatre sessions. Et la réponse était toujours la même : donner aux équipes un outil cadré.

Le point qui m’a le plus marqué, c’est que cet outil doit être bon. Chez Harmonie Mutuelle, l’outil interne sécurisé faisait moins de choses que ChatGPT, donc les gens retournaient sur ChatGPT. Au Sicoval, une IA générative fermée est aujourd’hui très sous-utilisée. Et si l’outil interne déçoit, les gens sortent leur téléphone perso.

Pour nous, un cadre, ce sont des règles plus un outil qu’on maintient à niveau dans la durée. Ça demande un budget de fonctionnement, pas seulement un projet de déploiement. C’est aussi pour ça que nos formations commencent toujours par regarder les usages actuels des équipes, y compris ceux que personne n’a cadrés.

Le modèle compte moins que ce qu’on construit autour

Les modèles changent toutes les semaines, et les meilleurs dans six mois ne sont pas encore sortis. Bâtir un projet autour d’un modèle précis, c’est s’obliger à le reconstruire plus tard. C’est la conviction la plus partagée de la journée, et c’est aussi la nôtre.

Concrètement, il faut une couche entre les applications et les modèles. Numih France utilise par exemple LiteLLM, une passerelle open source qui donne une seule porte d’entrée vers des dizaines de fournisseurs, et c’est ce qu’on utilise chez Atecna également. Chaque nouveau modèle passe sur leurs propres tests avant une bascule progressive. Pascal Basset va plus loin : ce qu’il faut maîtriser, c’est la plateforme où l’on construit et où tournent les agents, pas le modèle. Sur un de nos projets, on change déjà de fournisseur de modèle par un simple paramètre, et ça devrait être la norme dès qu’un projet part en production.

Deuxième conséquence : on choisit le modèle selon la tâche. Harmonie Mutuelle a validé un POC avec un modèle très puissant, qu’elle ne peut pas mettre en production parce qu’il coûte trop cher au volume. Chez U, une équipe d’architectes, de juristes et d’acheteurs choisit le modèle pour chaque besoin. Notre réflexe : estimer le coût en production dès le POC. Sinon, on démontre une valeur qu’on ne pourra jamais payer.

Et les prix vont bouger. Selon Fabrice Amatulli, les fournisseurs américains ne pourront pas subventionner leurs tokens indéfiniment : le « buffet à volonté » touche à sa fin. Un projet qui ne peut pas changer de modèle subira ces hausses sans pouvoir rien y faire.

Héberger un modèle ne suffit pas à le rendre souverain

« La souveraineté, c’est l’hébergement. » La formule de Fabrice Amatulli est efficace, et elle a du vrai. Un modèle open-weight (dont seuls les paramètres sont publiés) qui tourne sur vos serveurs ne fait pas sortir vos données, qu’il vienne de Chine, des États-Unis ou de France. Et ces modèles tournent aujourd’hui sur du matériel bien plus léger qu’il y a un an.

Mais la session sur les dépendances a apporté la nuance qui manquait : un modèle open-weight ne dit rien de la façon dont il a été entraîné. L’empoisonnement des données, c’est-à-dire des données d’entraînement volontairement biaisées, inquiète les responsables sécurité. L’hébergement règle la question des données, pas celle du comportement du modèle.

Notre position : utiliser ces modèles, oui, mais les tester sur nos propres cas avant de leur faire confiance, et garder une relecture humaine de ce qu’ils produisent, surtout quand c’est du code. On aime bien aussi l’idée d’Alain Issarni de « garder trois fers au feu » : modèles américains, open-weight et européens, pour ne dépendre d’aucun.

Et puis il y a le contrat, dont on parle assez peu. Alain Issarni a posé la question à la salle. Tout le monde a des données sensibles, personne ne veut qu’elles partent chez un tiers, mais très peu l’exigent par contrat de leurs fournisseurs. Les clauses Libralis sont libres d’utilisation : pas de transmission de données sans accord, pas de coupure arbitraire d’un service critique. Ça ne coûte rien de les ajouter à un appel d’offres.

Un pilote réussi, et après ?

Julien Rivière a ouvert la session sur le passage à l’échelle avec une histoire que toute la salle reconnaissait : un pilote réussi, une équipe convaincue, et six mois plus tard plus rien. Le pilote marchait très bien, personne n’avait décidé de la suite.

Pour nous, le passage à l’échelle se prépare dès le cadrage du pilote. Qui décidera de généraliser ? Sur quels critères ? Avec quel budget ? Tant que ces questions restent sans réponse, on fabrique des démos.

Les leçons partagées par Élise Savarese, tirées d’une quinzaine de projets chez Harmonie Mutuelle, sont la meilleure check-list entendue de la journée. En plus des deux évoquées plus haut (l’outil interne à la traîne et le modèle trop cher), on retient :

  1. La qualité des données d’abord. Un projet a été arrêté six mois, le temps de remettre les documents à niveau : versions périmées, scans illisibles pour l’IA.
  2. Des agents spécialisés. Un agent généraliste branché sur toute la base de connaissances donnait tellement d’informations que les utilisateurs perdaient du temps à tout lire.
  3. L’intégration au SI. Un chatbot limité à une FAQ, pour éviter les hallucinations, ne pouvait pas répondre sur les remboursements, et renvoyait vers le centre d’appels.

Enfin, Olivier Siegler a mis le doigt sur ce qui manque le plus souvent : « la vraie difficulté, c’est de mesurer le point de départ et le point d’arrivée ». On est tout à fait d’accord. C’est pour ça qu’on fixe avec nos clients un indicateur métier mesuré avant le projet, et remesuré de la même façon à la fin.

Les agents IA arrivent, leur sécurité n’est pas prête

Tout le monde parle d’agents, mais dès que la discussion arrivait sur la sécurité, le ton changeait. Aldrick Zappellini l’a dit sans détour : d’un point de vue industriel, l’agentique n’est pas mature, et les surfaces d’attaque sont immenses. MCP, le protocole qui connecte les agents aux outils et aux données, a encore pas mal de failles. Olivier Siegler, lui, s’inquiète de l’identité des agents : aujourd’hui, rien ne permet vraiment d’identifier proprement un agent et ce qu’il a le droit de faire.

On partage cette inquiétude, et on ajoute un risque qu’on a peu entendu : l’injection de prompt. Un agent qui lit des mails, des tickets ou des documents lit du texte écrit par d’autres. S’il le prend pour une consigne, il peut être détourné. Bien rédiger le prompt aide à filtrer, mais ça ne suffit jamais : les droits et les vérifications doivent se faire dans le code de l’application, hors du modèle.

Ce qui nous rassure, c’est que personne n’a parlé d’agents autonomes du jour au lendemain. Wafaa Amal a décrit la bonne progression : l’agent commence par lever une alerte qu’un humain valide, et on ne l’automatise qu’avec assez de recul en conditions réelles. C’est le principe du human in the loop. Il faut aussi pouvoir tracer en temps réel qui a fait quoi, humain ou agent, et avec quels droits. Chez U, Pascal Basset garde un contrôle humain sur le code produit, les tests et la validation, parce que le niveau de confiance n’est pas encore atteint.

L’IA sert aussi la défense. Numih France annonce un test d’intrusion de deux à trois semaines ramené à une heure. Fabrice Amatulli a lui-même reconnu que c’était provocateur, et tant qu’on ne sait pas comment c’est mesuré, on prend le chiffre avec des pincettes. La tendance, elle, est réelle : les modèles trouvent déjà des failles vieilles de vingt ans, et les attaquants y ont accès aussi.

Le vrai chantier est humain

Toutes les sessions ont fini sur la même conclusion : la technique avance très vite, et ce qui freine, c’est l’organisation. Julien Rivière a cité un chiffre qui résume tout : dans un programme chez Airbus, sur 600 cas d’usage retenus, deux ou trois seulement sont arrivés en production.

Après, l’idée qui nous a le plus parlé, c’est l’entonnoir décrit par Aldrick Zappellini. Si les développeurs vont trois fois plus vite mais que le métier, la mise en production et la sécurité restent au même rythme, on a juste déplacé le bouchon.

Côté métiers, Laetitia Routaboul a bien posé le problème : on ne leur demande plus d’utiliser un outil, on leur demande de déléguer l’exécution. C’est un changement d’une autre nature, qui touche à la confiance et à la place de chacun. La Région Occitanie met d’ailleurs le dialogue social sur la transformation des métiers dans ses priorités, et le Sicoval a fait le choix de la transparence avec ses habitants, en disant clairement où il utilise l’IA et où il ne l’utilise pas, comme dans ses recrutements.

Sur la formation, on se retrouve complètement dans ce qu’a dit Baptiste Laurut : l’IA ne s’apprend pas en théorie, il faut la pratiquer. Les bonnes pratiques changent en quelques semaines, une formation purement théorique est vite dépassée. C’est pour ça que nos formations ont peu de théorie et beaucoup de pratique, sur les vraies tâches des équipes. C’est aussi de lui que vient notre phrase préférée de la journée : il veut que ses équipes sachent dire aux métiers « là, tu as besoin d’un agent ; là, c’est un problème de paramétrage ; là, de processus ». Parfois, la bonne réponse est de ne pas mettre d’IA du tout.

Dernier point : garder des compétences en interne. Quand on explique à Aldrick Zappellini qu’il faut réduire le nombre de gens qui conçoivent ou supervisent, il répond que c’est exactement le contraire qu’il faut faire. On le rejoint. Ces compétences permettent de choisir ses outils au lieu de les subir, et il faudra les remettre à jour à peu près tous les deux ans.

Et on fait quoi ?

Si vous vous lancez (ou si ça bloque un peu), voilà ce qu’on ferait à votre place :

  • Donnez un cadre plutôt que d’interdire, avec un outil interne assez bon pour qu’on n’ait pas envie d’aller ailleurs.
  • Construisez pour pouvoir changer de modèle, et choisissez-le selon la tâche et son coût en production.
  • Testez les modèles open-weight sur vos propres cas avant de leur faire confiance, et blindez vos contrats.
  • Décidez dès le pilote qui tranchera la généralisation, et mesurez votre point de départ.
  • Traitez la sécurité des agents comme un sujet à part entière : identité, droits, traçabilité, validation humaine.
  • Mettez autant d’énergie dans l’adoption et la formation que dans la technique.

Rien de révolutionnaire là-dedans, et honnêtement c’est plutôt rassurant : ceux qui avancent le plus vite ont surtout fait ce travail de fond, quel que soit le modèle qu’ils utilisent.

Si vous étiez à la Mêlée, ou si vous vivez ces sujets chez vous, je suis curieux d’avoir votre avis 🙂

Florian Chevallier, responsable innovation chez Atecna