Développement d’outils IA sur mesure à Paris

Lorsque le besoin dépend de vos données, de vos règles ou de vos systèmes, et qu’aucune solution du marché ne le couvre sans compromis important.

La question précède toujours celle de l’outil : qu’est-ce qui, dans ce besoin, vous est propre. Si la réponse est « rien », une solution existante coûtera moins cher et sera maintenue par son éditeur. Nous le disons régulièrement, y compris quand cela nous retire le projet.

Trois situations justifient le sur-mesure. Le corpus est interne et sa structure vous est particulière — une documentation technique, un fonds de dossiers, une nomenclature métier. La règle de décision est votre savoir-faire et vous ne souhaitez pas la confier à un éditeur. Ou l’outil doit s’insérer dans un enchaînement existant avec des droits fins, ce que les solutions génériques font mal.

Un quatrième argument revient souvent et mérite d’être examiné plutôt qu’accepté : le coût par utilisateur. Une licence à quarante euros par mois pour deux cents personnes représente près de cent mille euros par an, et un développement devient compétitif.

Souvent. Un prototype vérifie la faisabilité sur des cas réels avant d’engager un développement complet, avec des critères d’évaluation définis.

Le prototype utile n’est pas une démonstration : c’est une mesure. Il prend vos données réelles, traite trente à cinquante cas dont on connaît la bonne réponse, et produit un taux. Ce chiffre décide de la suite mieux qu’une réunion.

Compter de cinq à quinze jours selon le sujet. Le critère d’arrêt est fixé avant : par exemple quatre-vingt-cinq pour cent de réponses exactes sur le jeu de référence, avec les erreurs restantes détectables. Sous ce seuil, nous ne recommandons pas d’aller plus loin sans un travail préalable sur les données.

Ce que le prototype ne dit pas : le coût d’exploitation à l’échelle, la tenue en charge, et l’adoption. Il faut se garder d’en tirer plus qu’il ne montre — un prototype réussi sur cinquante cas n’est pas un produit.

Et il est jetable. Le code du prototype n’est pas la base du développement : le confondre est la manière la plus sûre de construire un produit fragile.

Oui. L’interface, la logique, les intégrations, la sécurité, l’observabilité et le déploiement font partie du périmètre.

C’est un point qui distingue un outil d’une démonstration. Un modèle qui répond bien ne fait pas un produit : il faut une interface où l’utilisateur comprend ce qu’il regarde, la gestion des comptes et des droits, l’historique, la trace de ce qui a produit chaque réponse, les cas d’erreur, les limites d’usage, et les tableaux de suivi.

En répartition de charge sur un projet type, la partie « intelligence » représente rarement plus d’un quart du travail. Les trois autres quarts sont du développement classique — et c’est précisément ce que les estimations trop basses omettent.

S’y ajoute l’observabilité, particulière à ces systèmes : il faut pouvoir répondre, un mois plus tard, à la question « pourquoi le système a-t-il répondu cela ». Cela demande de conserver la question, les passages retrouvés, la version du modèle et des consignes, et la réponse produite.

Nous concevons cette traçabilité dès le départ, parce qu’elle ne s’ajoute pas après.

À vous. Le code, la documentation, les configurations et les accès sont remis dans les conditions prévues au contrat.

L’inventaire de livraison comprend le dépôt avec son historique, les consignes données au modèle — qui font partie du produit et représentent une part du travail —, les jeux d’évaluation constitués pendant le projet, la configuration d’indexation, les procédures de déploiement et la documentation d’architecture.

Les jeux d’évaluation méritent une mention particulière : ils sont souvent le livrable le plus durable. Ils permettent de vérifier qu’un changement de modèle ou de consignes n’a pas dégradé la qualité, et ils vous appartiennent — sans eux, un repreneur avance à l’aveugle.

Ce qui n’est pas cédé et qui doit être nommé : les licences des modèles et services tiers, qui restent régies par leurs conditions. Votre compte chez le fournisseur du modèle est à votre nom, ce qui vous permet de changer de prestataire sans changer de fournisseur, ou l’inverse.

C’est un point à vérifier dans tout devis, y compris les nôtres.

Oui si l’architecture le prévoit. Les systèmes sont conçus pour rester indépendants d’un fournisseur unique lorsque c’est possible.

La conception qui le permet : le modèle est appelé derrière une couche d’abstraction, les consignes sont des données et non du code, et le jeu d’évaluation permet de comparer deux modèles objectivement. Avec ces trois éléments, un changement se fait en quelques jours et se décide sur un chiffre.

Pourquoi c’est important : le marché bouge vite. Un modèle plus performant ou nettement moins cher apparaît tous les quelques mois, et les tarifs baissent. Un système verrouillé sur un fournisseur ne profite d’aucune de ces évolutions.

La limite honnête : les modèles ne sont pas interchangeables. Des consignes réglées finement pour l’un donnent des résultats différents avec l’autre, et il faut les reprendre. Le changement n’est donc pas gratuit — comptez de deux à cinq jours d’ajustement et de réévaluation.

Nous documentons donc, pour chaque système livré, le modèle utilisé, sa version et ce qui dépend de ses particularités.

Par des jeux d’évaluation, des critères d’acceptation, des tests de non-régression et l’analyse des cas réels après mise en service.

Le jeu d’évaluation est constitué avec vous et il est la pièce maîtresse : des cas représentatifs avec la réponse attendue, y compris les cas difficiles, ambigus, incomplets et hors périmètre. Ces derniers comptent davantage qu’une démonstration idéale — un système qui répond bien aux questions faciles et invente sur les questions hors sujet est inutilisable.

Les critères d’acceptation sont chiffrés avant la mise en service : taux de réponses exactes, taux de refus corrects quand l’information est absente, et absence d’erreur sur une liste de cas critiques.

Les tests de non-régression rejouent ce jeu à chaque modification — un changement de consignes, une mise à jour de modèle, un ajout de documents. C’est ce qui permet d’évoluer sans dégrader, et son absence explique la plupart des systèmes qui se détériorent silencieusement.

Après mise en service, les cas réels sont échantillonnés et relus, et les échecs rejoignent le jeu de référence.

Un premier périmètre utilisable se situe généralement entre quelques semaines et quelques mois, selon les données, les intégrations et le niveau de qualité exigé.

Trois ordres de grandeur, hors coûts récurrents. Un assistant documentaire sur un corpus propre et sans intégration : de vingt à trente-cinq jours de travail. Le même avec des droits par utilisateur, des sources multiples et une connexion à un système de gestion : de quarante à soixante-dix jours. Un outil qui décide et agit dans vos systèmes, avec traçabilité et validation humaine : davantage, et il se découpe en lots.

Ce qui déplace le chiffre, par ordre d’effet : l’état des données, qui peut ajouter un chantier de préparation entier ; le nombre de systèmes à connecter ; et le niveau de qualité exigé, car passer de quatre-vingts à quatre-vingt-quinze pour cent de réponses exactes coûte souvent autant que tout le reste.

Les récurrences sont dites séparément : appel aux modèles facturé à l’usage, hébergement, et maintenance. Nous plafonnons la dépense d’usage avec une alerte.

Oui. La formation porte sur l’usage réel, les limites du système, la lecture des résultats et les cas nécessitant une vérification humaine.

La partie sur les limites est la plus importante et la plus souvent absente. Un utilisateur qui croit que le système ne se trompe jamais ne vérifie rien ; un utilisateur qui ne lui fait aucune confiance ne l’utilise pas. La formation vise donc un usage lucide : sur quoi le système est fiable, sur quoi il ne l’est pas, et comment reconnaître une réponse douteuse.

Le format : une demi-journée par groupe d’utilisateurs, sur l’outil réel avec leurs propres cas, y compris des cas que nous savons mal traités — les montrer volontairement vaut mieux que les laisser découvrir.

S’y ajoute une formation courte des responsables sur la lecture des tableaux de suivi : taux de traitement, file d’exception, coût d’usage. C’est ce qui permet de piloter plutôt que de subir.

Le support remis est une suite de procédures avec vos propres écrans, et il mentionne explicitement ce que le système ne doit pas être utilisé pour faire.