Cadrage, données et critères de succès

Une équipe a passé six semaines à construire un outil d'IA pour lire des factures. En démo, c'était impeccable. Puis sont arrivées les vraies factures : reçus scannés, devises dans trois formats, un fournisseur qui écrit les dates « 3.4.26 ». Personne ne s'était mis d'accord sur ce que « ça marche » voulait dire, donc personne ne pouvait dire si l'outil était terminé. Il est sorti en retard, puis a été retiré.

Cette leçon sert à éviter ça. Avant d'écrire une ligne de code ou un seul prompt, vous décidez deux choses : à quoi ressemble le « bon » résultat (vos critères de succès) et quelles données vous avez réellement. Nous utiliserons un exemple fil rouge, un outil d'extraction de factures, du début à la fin.

L'erreur que presque tout le monde commet

La plupart des gens démarrent un projet d'IA par la solution : « Utilisons GPT pour lire nos factures. » C'est le mauvais premier geste.

Commencez plutôt par le résultat visé. Un résultat visé, c'est ce que vous voulez obtenir dans le monde réel, dit simplement :

« Nous voulons arrarrL'Annual Recurring Revenue (ARR) est le revenu normalisé et prévisible qu'une entreprise par abonnement attend de ses contrats actifs sur une année.Voir la définition complète →êter de saisir manuellement les totaux de factures dans notre système comptable. Une personne y passe 4 heures par jour. »

Remarquez que cela ne dit rien de l'IA. C'est une bonne chose. Vous pouvez maintenant demander : que devrait faire l'IA pour régler ça, et comment saurions-nous que ça fonctionne ?

Cadrage : réduire le problème jusqu'à ce qu'il soit concret

Cadrer, c'est tracer une frontière serrée autour de ce que votre outil fera et ne fera pas. Un périmètre large tue les projets. Un périmètre étroit les livre.

Périmètre vague : « Traiter automatiquement toutes nos factures. »

Périmètre serré : « Extraire cinq champs (nom du fournisseur, numéro de facture, date, total, devise) des factures PDF envoyées par nos 20 principaux fournisseurs, en anglais, vers un tableur. »

La version serrée est constructible cette semaine. Elle nomme les champs (les données précises que vous voulez), le format d'entrée (PDF) et la frontière (20 principaux fournisseurs, anglais uniquement). Tout ce qui est hors de cette frontière est un problème « pour plus tard », et le dire à voix haute fait partie du travail.

Notez ce qui est hors périmètre

Soyez explicite sur les exclusions. Pour l'outil de factures :

• Factures manuscrites : dehors.
• Langues autres que l'anglais : dehors pour l'instant.
• Factures multipages avec tableaux de lignes détaillées : dehors pour la v1.

Écrire les exclusions évite la dérive lente où quelqu'un demande « est-ce qu'il pourrait aussi gérer ce cas bizarre ? » et où le projet enfle.

Critères de succès : définir le « bon » comme un chiffre

Voici la règle : si vous ne pouvez pas le mesurer, vous ne pouvez pas le finir.

« Lire les factures avec précision » n'est pas un critère de succès. C'est un souhait. Transformez-le en quelque chose qui se compte.

Critère de succès : l'outil extrait correctement au moins 95 % des champs sur un jeu de test de 100 factures réelles.

Maintenant, « terminé » a une définition. Vous lancez l'outil, comptez les bonnes réponses et obtenez un chiffre. En dessous de 95 %, on continue. À 95 % ou plus, on livre.

Comment choisir le chiffre

N'inventez pas 95 % au hasard. Ancrez-le dans le réel :

• Quelle est la référence humaine ? Si un employé fatigué qui saisit à 17 h obtient 97 % des champs justes, votre barre se situe dans ces eaux-là.
• Quel est le coût d'une erreur ? Un mauvais nom de fournisseur est agaçant. Un total erroné de 40 000 $ est une catastrophe. Vous voudrez peut-être une cible plus stricte sur les champs à enjeu élevé.

Cela mène à un critère plus fin, qui pondère ce qui compte :

99 % de justesse sur le total et la devise, 95 % sur le reste, et chaque extraction à faible confiance signalée pour vérification humaine.

Cette dernière partie compte. Un outil qui dit « je ne suis pas sûr de celle-là » est bien plus sûr qu'un outil qui devine avec aplomb. Intégrez ce signalement dès le départ.

Décidez comment vous mesurerez avant de construire

Il vous faut un jeu de test : un ensemble figé d'exemples réels dont les bonnes réponses ont été renseignées par un humain. C'est votre corrigé.

Pour l'outil de factures, cela signifie prendre 100 factures réelles et noter manuellement les cinq champs corrects pour chacune, dans un tableur. Oui, à la main. C'est ennuyeux et c'est l'heure la plus rentable du projet. Sans ça, vous devinez.

Le « People + AI Guidebook » de Google propose une section claire et gratuite sur la définition du succès et des fonctions de récompense pour les produits d'IA si vous voulez creuser.

Auditez vos données avant de leur faire confiance

Maintenant la seconde moitié : les données. Votre outil d'IA ne vaut que ce que vous lui donnez. Avant de construire, auditez ce que vous avez réellement.

Ouvrez 30 factures réelles et regardez. Ne théorisez pas. Regardez. Vous trouverez des surprises à chaque fois :

• 12 sont des PDF numériques propres.
• 9 sont des scans, légèrement de travers, un est à l'envers.
• 5 sont des photos prises au téléphone.
• 3 utilisent un format de date auquel vous ne vous attendiez pas.
• 1 est une « facture » de fournisseur qui est en réalité un e-mail transféré.

Cet exercice de cinq minutes vient de remodeler votre projet. Les photos de téléphone et les scans nécessitent un traitement différent des PDF propres. Celle à l'envers échouera si vous ne l'anticipez pas.

Trois questions pour tout jeu de données

1. Est-il représentatif ? Vos 30 échantillons correspondent-ils à ce que l'outil verra en production ? Si vous ne testez que sur des PDF propres alors que 40 % des factures réelles sont des scans, votre score de 95 % est un mensonge.
2. Est-il labellisé ? Disposez-vous des bonnes réponses (les « labels ») pour comparer ? Sinon, c'est votre première tâche.
3. Est-il autorisé ? Pouvez-vous, légalement et éthiquement, transmettre ces données à un service d'IA ? Les factures contiennent des noms de fournisseurs, des coordonnées bancaires, parfois des informations personnelles. Vérifiez si vous pouvez les envoyer vers une APIAPIApplication Programming Interface : une interface standardisée qui permet aux applications de communiquer et d'échanger des données sans connaître leur fonctionnement interne respectif.Voir la définition complète → externe ou si elles doivent rester en interne.

Ce troisième point est bien réel en 2026. Des outils comme ChatGPT, Claude et Gemini proposent des offres entreprise qui n'entraînent pas leurs modèles sur vos données, mais les offres grand public gratuites peuvent le faire. Sachez laquelle vous utilisez avant de téléverser les documents financiers d'un client.

Mise en pratique : un premier test exécutable

Une fois que vous avez un périmètre, un chiffre de succès et un jeu de test audité, votre première construction est minuscule : passer quelques factures dans un modèle et voir où vous atterrissez. Les modèles récents comme Claude et Gemini acceptent directement un document et un prompt, donc le « code » se résume surtout à une instruction claire.

Voici un exemple minimal avec l'API Anthropic. Il demande les champs sous forme de données structurées (JSON), ce qui facilite la comparaison avec votre corrigé.

import anthropic, json

client = anthropic.Anthropic()  # utilise votre clé API depuis l'environnement

prompt = """Extract these fields from the invoice text below.
Return ONLY valid JSON with keys: vendor, invoice_number, date, total, currency.
If a field is missing or unclear, use null. Do not guess.

INVOICE TEXT:
{invoice_text}
"""

invoice_text = "ACME Corp  Invoice #4471  Date: 12 Jan 2026  Total: 1,250.00 USD"

msg = client.messages.create(
    model="claude-sonnet-4-5",
    max_tokens=300,
    messages=[{"role": "user", "content": prompt.format(invoice_text=invoice_text)}],
)

result = json.loads(msg.content[0].text)
print(result)
# {'vendor': 'ACME Corp', 'invoice_number': '4471',
#  'date': '2026-01-12', 'total': 1250.00, 'currency': 'USD'}

Deux choix de conception portent ici toute la leçon :

• « Do not guess. » Cela pousse le modèle vers null plutôt que vers des réponses fausses assénées avec assurance, ce qui alimente votre signalement pour revue humaine.
• Sortie JSON structurée. Comme la réponse revient sous forme de champs nommés, vous pouvez la comparer automatiquement au corrigé de votre tableur et calculer ce chiffre de 95 %.

Scorer contre votre corrigé

La boucle de scoring consiste simplement à compter les correspondances :

def score(predicted, correct):
    fields = ["vendor", "invoice_number", "date", "total", "currency"]
    hits = sum(1 for f in fields if predicted.get(f) == correct[f])
    return hits / len(fields)

# Exécutez ceci sur les 100 factures de test, puis faites la moyenne des scores.
# Cette moyenne EST votre métrique de succès.

Lancez-la sur les 100, faites la moyenne, et vous avez un chiffre honnête. Vous pouvez maintenant décider : améliorer le prompt, traiter les scans à part, ou livrer.

🎬 [VIDEO: "How to Evaluate LLMLLMUn Large Language Model est un système d'IA entraîné sur d'énormes volumes de texte pour prédire et générer du langage, ce qui permet de rédiger, résumer ou répondre à des questions.Voir la définition complète → Outputs" - youtube.com - une démonstration pratique de la construction d'un petit jeu de test et du scoring de la précision d'un modèle avant de passer à l'échelle]

L'état d'esprit

Tout l'enjeu est de remplacer les opinions par des preuves. « Ça a l'air plutôt bien » devient « ça score 91 %, et les échecs sont tous des photos de téléphone ». Cette seconde phrase vous dit exactement quoi corriger ensuite.

Définissez le bon, auditez vos données, construisez la plus petite chose qui produit un chiffre, puis améliorez. Tout projet d'IA sérieux, de l'outil de factures à une personne au système à l'échelle de l'entreprise, tourne sur cette boucle.

Points clés à retenir

• Partez du résultat visé, pas de l'outil. Nommez d'abord le résultat réel (« arrêter de saisir les factures à la main »), puis décidez de ce que l'IA doit faire pour y arriver.
• Cadrez serré et notez les exclusions. Cinq champs extraits de PDF anglais de vos 20 principaux fournisseurs, ça se livre cette semaine. « Toutes les factures », ça ne se livre jamais.
• Faites du « bon » un chiffre, avec un jeu de test. Labellisez à la main 100 exemples réels, puis mesurez-vous à eux. « 95 % des champs corrects, total et devise à 99 % » est une ligne d'arrivée ; « précis » ne l'est pas.
• Auditez les données en les regardant. Ouvrez 30 échantillons réels avant de construire. Vérifiez qu'ils sont représentatifs, labellisés et légalement admissibles dans l'outil d'IA que vous avez choisi.
• Demandez une sortie structurée et « ne devine pas ». Les champs JSON rendent le scoring automatique, et signaler les cas à faible confiance pour revue humaine tient les erreurs coûteuses hors de la production.