01 Implémentation d’IA et conception de systèmes

Nous concevons le système autour du modèle.

Les projets d’IA échouent rarement au niveau du prompt. Ils échouent au niveau de la recherche d’information, de la qualité des données, de l’évaluation, de la latence et du coût, et de ce qui se passe quand le modèle se trompe avec assurance. C’est de l’architecture de systèmes, et c’est ce que George fait depuis vingt ans.

La vérité peu glamour sur les produits d’IA

Un modèle de langage est une dépendance que vous appelez sur le réseau. Il est non déterministe, il est facturé au token, il est plus lent que votre base de données, et il renverra de temps à autre une réponse plausible et fausse.

Tout ce qui détermine si votre fonctionnalité d’IA fonctionne en production relève d’une architecture logicielle ordinaire et difficile : quel contexte vous récupérez et comment, comment vous mesurez si une réponse était bonne, ce que vous mettez en cache, ce que vous faites quand le fournisseur est indisponible, comment vous empêchez le coût de croître avec votre succès. C’est là le travail, et c’est ce que nous faisons.

02 Là où nous intervenons

De « faut-il utiliser l’IA ? » à un système en production

Les missions commencent en général en haut de cette liste et descendent progressivement. Vous êtes libre de vous arrêter après la première.

01

Évaluation des opportunités d’IA

Une mission courte et rémunérée qui examine votre produit et vos données, puis vous indique où l’IA crée de la valeur, où elle ne fait qu’engendrer des coûts, et ce que sa mise en œuvre demanderait. Vous repartez avec un plan écrit. Parfois, la réponse honnête est « pas encore », et nous vous le dirons.

  • Liste restreinte de cas d’usage, classés par valeur et par risque
  • Revue de maturité des données
  • Recommandation : construire, acheter ou attendre
02

Conception de systèmes d’IA

L’architecture autour du modèle : comment le contexte lui parvient, comment vous savez que la sortie est bonne, ce qu’elle coûte par requête, à quelle vitesse elle répond, et comment le produit se dégrade en douceur quand le modèle ou le fournisseur défaille.

  • Conception de la recherche d’information et des pipelines de données
  • Bancs d’évaluation et garde-fous qualité
  • Budgets de coût et de latence
  • Solutions de repli, cache et dégradation progressive
03

Fonctionnalités LLM dans des produits existants

L’essentiel de ce travail se déroule au sein d’applications qui ont déjà des utilisateurs et des revenus. Nous ajoutons la fonctionnalité sans déstabiliser ce qui génère déjà de l’argent, une contrainte que les démos d’IA greenfield n’ont jamais à respecter.

  • Génération augmentée par récupération (RAG) sur vos propres contenus
  • Extraction structurée et classification
  • Agents et utilisation d’outils, cadrés pour qu’ils ne puissent pas nuire
  • Assistants et recherche sémantique
04

Automatisation des processus et des workflows

La catégorie la moins à la mode et la plus rentable : le travail manuel, répétitif et pauvre en jugement au sein de votre activité, qu’un modèle bien cadré peut absorber, un humain gardant la main sur les décisions qui comptent.

  • Traitement de documents et d’e-mails
  • Workflows de back-office et de support
  • Étapes de validation avec intervention humaine

Choix du modèle et du fournisseur

Les modèles changent tous les quelques mois ; l’architecture qui les entoure ne devrait pas avoir à le faire. Nous gardons le fournisseur derrière une interface, choisissons le modèle le moins cher qui franchit votre seuil de qualité plutôt que le plus gros disponible, et faisons du changement une affaire de configuration plutôt qu’une réécriture.

03 Pourquoi nous

Un architecte, pas un prompt engineer

Le prompting est une compétence qui s’apprend en quinze jours. Savoir quelle partie d’un système va céder sous la charge prend nettement plus de temps.

Vingt ans de systèmes en production

Des API à fort trafic, des modèles de données qui ont survécu à une vraie croissance, et des plateformes livrées sans interruption. Les fonctionnalités d’IA vivent à l’intérieur de systèmes comme ceux-là, sinon elles ne quittent jamais la démo.

Vous obtenez l’ingénieur, pas un chargé de clientèle

La personne qui cadre votre projet est celle qui l’architecture et écrit le code. Rien ne se perd dans la passation, parce qu’il n’y a pas de passation.

Dit sans détour, mauvaises nouvelles comprises

Si l’IA est le mauvais outil pour votre problème, c’est le conseil que vous recevrez dès la première semaine, avant que le budget ne soit dépensé. Cette conversation coûte moins cher que l’alternative.

Un problème d’IA qui vaut la peine d’être résolu ?

Dites-nous ce que vous cherchez à construire. Si c’est une bonne adéquation, nous vous le dirons, et si ce n’en est pas une, nous vous le dirons aussi.