De l'IA dans un logiciel qui tourne, pas dans une démonstration

La demande arrive en chatbot, le problème est ailleurs

Quand une société demande un chatbot, ce qu'elle veut presque toujours, c'est qu'un collaborateur ou un client trouve une information en dix secondes au lieu de dix minutes. C'est un problème de recherche. Une recherche correcte, avec des filtres, des résultats datés et un lien vers la source, répond mieux, se maintient moins cher et ne se trompe pas.

L'autre moitié des demandes est un problème de processus. Une saisie faite à la main, un document qui transite par cinq boîtes mail, une règle métier appliquée par habitude. Là non plus, la réponse ne commence pas par un modèle de langage. Elle commence par regarder le flux et supprimer les étapes qui n'ont plus de raison d'être.

Il reste de vrais cas où la conversation est la bonne interface : quand la question est ouverte, quand l'utilisateur ne sait pas quoi demander, quand il faut recouper plusieurs sources pour répondre. Ceux-là valent d'être construits. Pour les autres, vous l'entendrez avant le devis, pas après.

Un système de recherche augmentée ne vaut que ses documents

Le RAG a une propriété que les démonstrations masquent : il répond avec ce qu'on lui donne. Si votre base documentaire contient deux procédures contradictoires dont une périmée depuis trois ans, le modèle reprendra la contradiction avec le même aplomb que le reste.

La partie coûteuse d'un projet de ce type n'est donc ni le modèle ni la base vectorielle. C'est de décider qui est propriétaire de chaque document, ce qui fait autorité quand deux sources se contredisent, et par quel mécanisme une version obsolète sort de l'index. Si personne dans l'entreprise n'accepte cette responsabilité, le projet livrera un assistant confiant et faux, ce qui est pire que rien.

En pratique, nous demandons le corpus réel avant de chiffrer. Pas un échantillon choisi : l'ensemble, avec ses doublons, ses versions de 2019 et ses PDF scannés de travers. Son état détermine le reste du projet.

Du génératif face au client, à quelles conditions

Tout ce qui est génératif et visible par un client finira par produire une phrase que l'entreprise devra assumer. Ce n'est pas un risque à éliminer, c'est un risque à encadrer, et cela se décide avant la mise en ligne.

Il faut une sortie vers un humain, accessible en un clic, pas enterrée après six relances. Il faut un jeu d'évaluation, c'est-à-dire une liste de questions réelles avec les réponses attendues, rejouée à chaque changement de prompt, de modèle ou de corpus. Il faut pouvoir revenir en arrière et couper la fonctionnalité en quelques minutes, sans redéployer la moitié du produit.

Il faut enfin conserver la trace de ce qui a été demandé, de ce qui a été répondu et sur quelles sources. Le jour où un client conteste une réponse, c'est la seule chose qui permette de savoir ce qui s'est passé.

Où part votre donnée

Envoyer les documents de l'entreprise à un fournisseur de modèle tiers est une décision, avec des conséquences contractuelles et réglementaires. Elle peut être la bonne. Elle ne devrait pas se prendre par défaut, dans un fichier de configuration, parce que c'était le plus rapide à brancher.

Quand cela compte, le travail reste chez vous. Nos ingénieurs peuvent travailler dans votre tenant, sur votre infrastructure, sous vos contrôles d'accès, avec le modèle que votre direction a déjà validé. La donnée ne bouge pas. Le contrat, lui, passe par JADEV GROUP SARL, en Belgique, en euros, sous droit belge.

Sur la sécurité, la phrase exacte : nos pratiques suivent les principes ISO/IEC 27001 et sont alignées sur CyberFundamentals du Centre pour la Cybersécurité Belgique, avec l'audit de stade 2 prévu auprès d'un organisme accrédité BELAC en 2027. Nous ne sommes pas certifiés aujourd'hui, et vous ne lirez jamais le contraire ici.

Là où nous sommes la mauvaise réponse

Nous ne sommes pas un laboratoire de recherche. Nous n'entraînons pas de modèles de fondation et nous n'allons pas commencer. Si votre besoin est un modèle propre à votre domaine entraîné depuis zéro, ou une publication scientifique, ce n'est pas ici que cela se passe.

Nous ne sommes pas revendeurs et nous n'avons aucun statut de partenaire à afficher. Si ce qui vous rassure dans une réponse à appel d'offres est un badge de partenariat avec un fournisseur de modèle, d'autres en ont un et nous non.

Si votre besoin tient dans un produit du marché, achetez le produit. Un assistant de support générique, une transcription de réunion, une aide à la rédaction : cela existe pour quelques euros par utilisateur et par mois, et faire développer l'équivalent coûtera bien plus cher pour un résultat moins bon. Nous servons à ce qui doit se brancher sur vos systèmes, vos données et vos règles, ce qu'un produit sur étagère ne fait pas.

Enfin, si votre procédure d'achat exige une certification ISO 27001 valide à la signature, nous ne passons pas ce filtre aujourd'hui. C'est une raison légitime de nous écarter.

Comment c'est construit

Le socle technique est celui que nous utilisons partout ailleurs : Azure, .NET, Node, Next.js, React, TypeScript, PostgreSQL. Une fonctionnalité d'IA reste du logiciel, avec des tests, une intégration continue, des environnements et quelqu'un à appeler quand elle tombe. Ce qui la distingue, c'est qu'elle peut échouer en produisant quelque chose de plausible, et c'est pour cela que l'évaluation et la journalisation comptent plus que la seule supervision des erreurs.

Nous utilisons nous-mêmes un cycle de développement assisté par l'IA en interne, et nous écrivons dessus publiquement. Cela veut dire des gens qui ont vu où ces outils tiennent et où ils lâchent, sur leur propre code, avant de les mettre dans le vôtre.