Service
Services d'intégration de l'IA
Placée là où elle supprime du travail, pas là où elle se démontre bien.
Pour les équipes qui veulent de l'IA à l'intérieur des systèmes qu'elles exploitent déjà, pour des tâches précises : lire des documents, classer ce qui arrive, répondre à des questions sur leurs propres données, préparer des textes qu'une personne validera ensuite. Construit avec évaluation et maîtrise des coûts, car une fonctionnalité que personne ne peut mesurer est une fonctionnalité en laquelle personne ne peut avoir confiance.
La décision
Quand c'est le bon choix.
La plupart des fonctionnalités d'IA échouent des deux mêmes façons. Elles sont placées là où elles se voient plutôt que là où elles font gagner du temps, et elles sont livrées sans aucun moyen de savoir si leur sortie est juste. Un résumé faux une fois sur vingt est pire que pas de résumé du tout, parce que le vingtième cas est celui qui arrive chez le client.
Le deuxième échec, ce sont le coût et la latence découverts en production. Une invite correcte en test devient coûteuse à dix mille appels par jour, et une fonctionnalité à neuf secondes ne sera pas utilisée, si bonne soit-elle. Ce sont deux contraintes de conception, toutes deux peu coûteuses à traiter tôt et pénibles à rattraper ensuite.
Nous partons de la tâche plutôt que de la technologie : ce qui se fait à la main, à quelle fréquence, et ce que cela coûte quand c'est faux. Ensuite nous construisons un jeu d'évaluation avant la fonctionnalité, pour que la question de savoir si elle marche ait une réponse. Souvent, il s'avère qu'aucun modèle n'est nécessaire, et nous le disons.
Ce que vous obtenez
Ce que couvre la mission.
Extraction documentaire
Factures, bons de commande, relevés et formulaires lus dans des champs structurés, avec un indice de confiance affiché pour que les cas douteux aillent à une personne au lieu de passer en silence.
Classification et routage
Demandes entrantes, tickets et documents orientés vers la bonne file, avec des règles auditables plutôt qu'opaques.
Recherche sur vos propres données
Une recherche sur vos documents et vos enregistrements qui cite ses sources, pour qu'une réponse puisse être vérifiée plutôt que crue.
Rédaction soumise à une validation humaine
Réponses, résumés et descriptions préparés pour qu'une personne les valide. Cette validation est un choix de conception, pas un avertissement.
Évaluation avant la mise en service
Un jeu annoté et un taux de réussite mesuré, pour qu'un changement d'invite ou de modèle devienne une comparaison plutôt qu'une intuition.
Maîtrise du coût et de la latence
Cache, routage des modèles selon la difficulté et alertes budgétaires, car une tarification à l'appel devient une facture mensuelle que personne n'avait chiffrée.
Stack
Avec quoi nous le construisons.
Choisis projet par projet. Rien n'est imposé par défaut ici, et l'équipe qui assurera la maintenance pèse autant que le problème.
Modèles
Claude, GPT ou un modèle à poids ouverts, choisi tâche par tâche sur une qualité et un coût mesurés plutôt que sur la marque.
Recherche documentaire
PostgreSQL avec pgvector là où cela suffit, un magasin vectoriel dédié là où le volume le justifie.
Orchestration
Du code simple et lisible de préférence. Les frameworks d'agents lourds seulement quand ils rentabilisent leur coût de débogage.
Évaluation
Des jeux de tests versionnés exécutés dans le pipeline, pour qu'une régression soit prise en intégration continue et non par un client.
Confidentialité
Localisation des données, durée de conservation et expurgation décidées avant le premier appel, y compris la question de savoir si une requête a le droit de quitter votre infrastructure.
Comparaison
IA plaquée ou IA qui mérite sa place.
La plupart des fonctionnalités d'IA échouent des deux mêmes façons : elles sont placées là où elles se voient plutôt que là où elles font gagner du temps, et elles sont livrées sans aucun moyen de savoir si leur sortie est juste.
| Critère | IA ajoutée par-dessus | Comment nous le construisons |
|---|---|---|
| Où cela mène | Là où cela se démontre bien — une zone de discussion sur le tableau de bord | Là où se trouve réellement le travail manuel, ce qui est rarement spectaculaire |
| Savoir que cela fonctionne | Quelqu'un l'a essayé quelques fois et cela semblait correct | Un jeu annoté issu de vos cas réels, avec un taux de réussite mesuré avant la mise en service |
| Quand il n'est pas sûr | Répond quand même, avec la même assurance que lorsqu'il a raison | Tout ce qui passe sous votre seuil va à une personne, et ce seuil, c'est vous qui le fixez |
| Coût | Découvert sur la facture du premier mois | Estimé pendant le cadrage, avec cache, routage des modèles et alerte budgétaire |
| Latence | Découverte en production, après quoi la fonctionnalité cesse discrètement d'être utilisée | Une contrainte de conception chiffrée, car une fonctionnalité à neuf secondes ne sera pas utilisée |
| Changer l'invite ou le modèle | Un changement que personne ne peut évaluer, donc personne n'ose le faire | Une comparaison mesurée sur le même jeu de tests, exécutée en intégration continue |
Comment cela se déroule
De la première conversation à la mise en ligne.
Indicatif pour un travail de cette nature. Le pilote n'est pas optionnel — rien n'est basculé tant que les utilisateurs n'ont pas dit que cela tient.
- 1 semaine
Identifier le travail
Ce qui se fait à la main, à quelle fréquence, et ce que cela coûte quand c'est faux. Parfois la réponse est une règle ou un meilleur formulaire, et nous le disons.
- 1 semaine
Construire le jeu d'évaluation
Des cas réels, annotés, avant que la fonctionnalité n'existe. Sans cela, impossible de distinguer une amélioration d'une régression.
- 3 à 5 semaines
Construire et mesurer
L'intégration, la validation humaine, le cache et la maîtrise des coûts, mesurés sur le même jeu à chaque modification.
- 2 à 3 semaines
Pilote et réglage
En service sur une part du volume réel, avec une validation réglée prudemment, puis assouplie seulement dans la mesure où les chiffres mesurés le justifient.
Après la mise en service
Ce qui change.
- L'étape manuelle que la fonctionnalité devait supprimer disparaît vraiment, au lieu d'être seulement assistée.
- Les cas peu sûrs remontent à une personne au lieu de passer en silence, et c'est précisément ce qui rend la fonctionnalité sûre à laisser tourner.
- Changer d'invite ou de modèle devient une comparaison plutôt qu'un pari.
- La facture mensuelle est un chiffre que quelqu'un avait prévu, pas une surprise.
Décrit qualitativement à dessein. Nous ne publions pas de pourcentages d'amélioration que nous ne pouvons pas rattacher à un client nommé, avec son accord.
Questions
Questions fréquentes.
Nos données serviront-elles à entraîner le modèle d'un tiers ?
Pas avec les configurations que nous déployons. Les conditions des API d'entreprise excluent l'entraînement sur les données transmises, et là où cela ne convient pas, nous faisons tourner un modèle à poids ouverts sur votre propre infrastructure. Cela se décide avant toute intégration.
Comment savez-vous que l'IA a raison ?
Nous construisons un jeu d'évaluation annoté à partir de vos cas réels avant de livrer la fonctionnalité, et nous mesurons dessus. Tout ce qui passe sous le seuil convenu va à une personne au lieu de poursuivre, et ce seuil, c'est vous qui le fixez.
Combien coûte son exploitation ?
Cela dépend du volume et du modèle retenu, et nous l'estimons pendant le cadrage plutôt qu'après la mise en service. Le cache, l'orientation des cas simples vers des modèles moins chers et une alerte budgétaire mensuelle font partie du projet.
Avons-nous seulement besoin d'IA ?
Souvent non. Une règle bien placée, un meilleur formulaire ou un rapport figé résout une part surprenante de ce qui est cadré comme un problème d'IA, pour une fraction du coût et sans aucune incertitude. Quand c'est le cas, nous vous le dirons.
Pouvez-vous faire tourner un modèle sur notre propre infrastructure ?
Oui, avec un modèle à poids ouverts là où la localisation des données ou les clauses contractuelles l'exigent. L'arbitrage porte sur la qualité et la charge d'exploitation face au contrôle, et il mérite d'être tranché sur des résultats mesurés pour votre tâche réelle plutôt que sur un principe.
Et si l'IA se trompe devant un client ?
C'est exactement ce que la validation humaine et le seuil de confiance servent à éviter, et ce sont deux choix de conception faits avant la livraison, pas un avertissement ajouté après. Là où se tromper coûte cher, le bon réglage est de préparer pour validation et de ne jamais agir sans surveillance.