À la fin, quelque chose tourne. Ce n'est pas une salle de cours.
Une équipe, un cas d'usage réel, un format intensif encadré par des ingénieurs qui construisent ces systèmes tous les jours. À la sortie, un prototype fonctionnel sur vos données — et une équipe qui sait pourquoi il marche.
- Sur votre cas réel
- Encadré par des ingénieurs
- Un prototype à la sortie
Le fossé entre comprendre et savoir faire
On peut suivre dix heures de formation et rester incapable de lancer un projet. Le format y est pour beaucoup.
Comprendre n'est pas construire
Les concepts sont clairs en séance. Devant un vrai corpus, avec de vrais droits d'accès et de vraies contraintes, plus rien ne ressemble à l'exemple.
L'élan retombe
Entre la formation et le premier projet, il s'écoule des mois. Les décisions se diluent, les personnes changent de priorité, et rien ne démarre.
Personne n'ose se tromper
Sans espace pour échouer sans conséquence, les équipes ne testent que ce qu'elles maîtrisent déjà. Elles n'apprennent donc rien de neuf.
Le déroulé
Le cas est choisi avant le début, sur des données réelles. Le format ne fonctionne pas sur un sujet fictif.
Sélection du cas
Avant le début, nous choisissons ensemble un cas d'usage réel, utile et réalisable dans le format — étroit plutôt qu'ambitieux. Un cas trop large produit une démonstration inachevée, ce qui est démoralisant et inutile.
Préparation des données et des accès
Les données sont préparées et les accès ouverts avant le premier jour. Passer les deux premiers jours à attendre un droit d'accès est la façon la plus courante de rater ce format.
Fondations
Les concepts nécessaires au cas choisi, et uniquement ceux-là : ce qu'un modèle sait faire, ce qu'il rate, comment on branche une source, comment on vérifie une réponse. Une part minoritaire du temps.
Construction encadrée
L'équipe construit, un ingénieur est disponible en continu. Les impasses sont assumées : comprendre pourquoi une approche ne marche pas sur votre corpus vaut plus qu'une démonstration réussie sur un corpus choisi.
Restitution et suite
Le prototype est présenté, ses limites documentées, et la question posée franchement : faut-il l'industrialiser, le refaire autrement, ou l'abandonner. Les trois réponses sont acceptables.
Les cas qui marchent bien dans ce format
Le critère commun : un périmètre étroit et des données disponibles dès le premier jour.
Assistant sur un corpus délimité
Une base documentaire précise — procédures d'un service, catalogue produit, fonds réglementaire — rendue interrogeable.
Extraction documentaire
Sortir des champs structurés d'un type de document récurrent et les contrôler.
Analyse d'un jeu de données
Interroger un fichier ou une base en langage naturel et vérifier la justesse des résultats.
Automatisation d'une tâche
Un enchaînement simple, de bout en bout, avec un point de validation humaine.
Comparaison de documents
Détecter les écarts réels entre deux versions ou deux contrats.
Évaluation d'une approche
Trancher, sur vos données, entre deux façons de résoudre le même problème.
Ce que l'équipe emporte
- Un prototype fonctionnel sur votre cas et vos données réelles
- Le code et la configuration, documentés et réutilisables
- Les limites mesurées du prototype, chiffrées plutôt que ressenties
- Une recommandation franche : industrialiser, refaire autrement, ou arrêter
- Une équipe capable de recommencer seule sur un cas voisin
Questions fréquentes
Une petite équipe, mêlant des profils métier et techniques. Le format perd tout intérêt quand personne ne connaît le domaine ou quand personne ne sait construire.
Pas tout le monde. Il faut au moins une personne à l'aise techniquement dans l'équipe, et des personnes qui connaissent réellement le métier.
Oui, c'est la condition. Sur des données fictives, le format ne prouve rien et n'apprend rien d'utile.
Comme prototype, oui. En production, non : il manque la gestion des droits, la traçabilité et la robustesse. C'est la phase d'industrialisation qui les apporte.
C'est un résultat, et souvent le plus rentable : savoir en quelques jours qu'une piste ne tient pas évite un projet de six mois.
Les deux fonctionnent. Sur site, la dynamique d'équipe est meilleure ; en ligne, l'organisation est plus simple pour des équipes réparties.
Ce que cette solution ne fait pas
Un prototype de bootcamp n'est pas un système de production. Il n'a ni la gestion des droits, ni la traçabilité, ni la robustesse d'un système déployé — et le confondre avec un produit fini est la meilleure façon de décevoir tout le monde trois mois plus tard. Le format sert à trancher vite et à monter une équipe en compétence, pas à économiser une industrialisation.
Quel cas mérite d'être tranché rapidement ?
Si une question tourne en rond dans vos réunions depuis six mois, ce format y répond en quelques jours, sur vos vraies données.