La tâche d'abord, le modèle ensuite
Si des règles ou une recherche suffisent, pas de modèle. Si un modèle est nécessaire, le plus petit qui fait le travail.
Personne n'arrive au même endroit. Certains cherchent encore à savoir ce que la technologie fait vraiment, d'autres ont un outil qui tourne et ne tient que sur une personne. Cinq accompagnements, un par étape, chacun avec son cadre de travail et ce que vous emportez à la fin.
Comprendre avant d'acheter
Tout le monde parle d'IA chez nous, personne ne sait ce qu'on a le droit de faire.
Avant d'écrire une ligne de code, il faut que les gens qui décident sachent de quoi ils parlent. Pas une conférence : une mise à plat de ce que la technologie fait vraiment, de ce qu'elle coûte, et de ce que la loi vous demande depuis 2025.
Les trois familles, et elles n'ont rien à voir : le grand modèle généraliste, le petit modèle spécialisé, et l'automatisation sans modèle du tout. Le choix entre les trois est la première décision d'impact, avant toute optimisation.
Le règlement européen sur l'IA et son calendrier, le RGPD, l'obligation de dire à quelqu'un qu'il parle à une machine, et ce qui sort de chez vous quand un texte entre dans un prompt.
La liste des usages autorisés, la liste des usages interdits, et surtout qui tranche quand un cas nouveau se présente.
Un projet, un ROI
On a dix idées, on ne sait pas laquelle vaut le coup.
La plupart des projets d'IA échouent avant de commencer, parce qu'ils partent d'une idée et pas d'un geste. On inverse : on regarde ce que vos équipes refont tous les jours, on le chiffre, et on n'en garde qu'un.
Quatre temps, sur vos chiffres, pas sur des moyennes de marché.
Ce que quelqu'un refait chaque jour ou chaque semaine, en le nommant comme il le nomme lui. Une idée ne se mesure pas, un geste oui.
Combien de fois, combien de temps, à quel moment ça casse et qui repasse derrière. Aucun chiffre ne vient d'ailleurs que de chez vous.
Le gain attendu, la méthode qui servira à le vérifier après coup, et la charge qu'il faut y mettre. Un indicateur choisi maintenant, pas reconstruit à la fin.
C'est la partie qui fait gagner le plus de temps, et celle que personne ne fait.
Le périmètre écrit avant le code
On sait quoi faire, on ne sait pas comment le cadrer.
Un cadrage sert à une chose : rendre les mauvaises surprises visibles tant qu'elles ne coûtent rien. On écrit le système entier avant de le construire, dans les quatre actes qui composent notre métier.
Interfaces, données, expériences, process. Le même découpage que sur nos projets.
Un écran par geste réel, dans l'ordre où le travail se fait. Le périmètre se réduit avant de s'étendre.
Quelles entités existent vraiment, ce qui les relie, ce qui doit être unique, ce qui peut manquer. C'est la décision la plus coûteuse à corriger plus tard.
Où la machine décide, où elle propose, et où elle rend la main. Ce point de bascule s'écrit maintenant, pas quand un client se plaint.
Le déclencheur, le traitement, les sorties, le journal. Une automatisation muette est une automatisation dangereuse.
Sur vos données réelles
On a déjà eu une maquette. Elle n'a jamais servi.
C'est le cœur de notre métier : on envoie l'ingénieur là où le problème se pose. Il travaille chez vous, sur vos données réelles, et ce qu'il livre sert dès la première semaine. Une maquette qui ne touche pas le réel ne prouve rien.
Sur site, par lots, avec une sortie possible à chaque lot.
Sur site, avec vos accès et vos données réelles. Pas un jeu d'essai, pas un bac à sable qui ressemble à votre métier de loin.
Chaque semaine quelque chose qu'on peut utiliser, mis entre les mains de ceux qui font le travail. Ce sont eux qui disent si c'est bon.
L'indicateur choisi à l'étape 02, avant et après. Avec sa méthode, pas un pourcentage sorti de nulle part.
Un prototype qui ne déplace pas l'indicateur s'arrête. C'est écrit au départ, pour que ce ne soit pas une négociation à la fin.
Ce qui tient sans nous
Ça marche, mais ça ne tient que parce que quelqu'un y pense.
Un outil qui dépend d'une personne n'est pas un outil, c'est une dette. Cette étape sert à rendre le système exploitable par vos équipes, mesurable dans son coût, et réparable quand il casse.
Quatre chantiers, jusqu'à ce que vous n'ayez plus besoin de nous.
Qui voit quoi, qui peut quoi, avec un journal des actions sensibles. C'est ce qui permet à l'outil de sortir d'une équipe et de servir toute la maison.
Sauvegardes, restauration testée pour de vrai, alerte sur échec. Un traitement qui rate doit vous le dire, pas être découvert trois mois plus tard.
Ce que chaque usage consomme, suivi dans le temps, et ce qu'on retire quand ça ne sert pas. On n'utilise que ce qui est nécessaire.
Documentation d'exploitation, formation de vos équipes, et un interlocuteur qui connaît votre système quand vous en avez besoin.
Six règles qui s'appliquent au premier atelier comme au dernier déploiement. Elles viennent de notre mémo de position sur l'IA, et elles sont opposables : si nous les enfreignons sur votre projet, vous avez de quoi nous le dire.
Si des règles ou une recherche suffisent, pas de modèle. Si un modèle est nécessaire, le plus petit qui fait le travail.
Le système répond depuis vos contenus, dit d'où vient la réponse, et dit quand il ne sait pas.
Conseil, vente, arbitrage, relation. La machine oriente vers la personne compétente, elle ne prend pas sa place.
Hébergement identifié, pas d'entraînement sur vos échanges, propriété, export et suppression écrits au contrat.
L'appel au modèle est abstrait, un repli sans modèle existe, et rien ne dépend d'un acteur unique.
Un chiffre vient avec sa méthode et sa date. Jamais un pourcentage d'économie qu'on n'a pas mesuré.
Vous n'êtes pas obligé de passer par les cinq, ni de commencer par la première. La plupart des projets entrent à l'étape 02, parce que la cible n'est pas encore choisie. Un échange suffit pour le savoir.