Cas d'usage IA en entreprise : 5 patterns qui marchent en 2026
Quick Answer : par où commencer en cas d’usage IA ?
Au-delà de la conversation type ChatGPT, cinq cas d’usage IA ont fait leurs preuves en entreprise en 2026 — c’est-à-dire qu’ils tiennent la route en production et apportent un gain mesurable :
- Extraction documentaire — passer d’un PDF, d’une facture ou d’un contrat à des données structurées prêtes à intégrer dans un logiciel (gain typique : un facteur dix sur le temps de saisie).
- Classification et tri — catégoriser des mails entrants, des tickets, des dossiers, et les diriger vers le bon traitement.
- Automatisation de rapports et synthèses — transformer un ensemble de documents (transcriptions de réunions, dossiers, notes) en livrables structurés.
- Agents autonomes encadrés sur des tâches de niveau 3-4 (veille, planification, suivi), toujours sous supervision humaine sur les étapes critiques.
- Anonymisation et reconnaissance d’entités nommées (NER) — préparer des données pour la conformité ou pour les partager.
Chaque cas d’usage a un seuil de complexité très différent. Démarrer par l’extraction documentaire ou la classification offre généralement le meilleur ratio impact / risque. Les agents autonomes restent à manier avec prudence en 2026 — la promesse est forte, la maturité opérationnelle inégale et fortement dépendante du périmètre.
Pourquoi ce sujet, maintenant
Trois choses ont changé entre 2024 et 2026 sur le terrain des cas d’usage IA en entreprise.
Un, la frontière a bougé sur ce que l’IA fait fiablement. L’extraction documentaire, la classification, la synthèse de réunion sont passées du POC démonstratif au produit en production avec des métriques solides. Le cas typique extraction de factures hétérogènes affiche en 2026 des taux d’erreur inférieurs à la saisie humaine sur volume — ce qui n’était pas vrai en 2023.
Deux, le coût d’inférence a baissé d’un ordre de grandeur. Un cas d’usage qui coûtait 0,80 € par traitement en 2023 en coûte 0,05 à 0,15 € en 2026, à qualité équivalente ou supérieure. Beaucoup de cas d’usage marginaux sont passés au-dessus du seuil de rentabilité.
Trois, le cadre réglementaire s’est précisé. L’AI Act est entré en application progressive. La CNIL a publié des recommandations sectorielles. Les obligations sont claires — c’est une discipline, pas un frein. Les organisations qui s’y mettent en 2026 partent avec un cadre éclairci ; celles qui attendent une nouvelle clarification accumulent du retard.
Le marché s’est aussi assaini. Les promesses « l’IA va tout transformer » ont laissé place à des promesses calibrées : extraction documentaire fiable, tri de mails fiable, support de premier niveau augmenté. Ce guide est calé sur cette deuxième vague.
La grille des 4 niveaux d’usage IA, appliquée aux cas concrets
Avant d’évaluer un cas d’usage, il faut situer le niveau d’autonomie attendu. La grille à quatre niveaux (présentée dans notre guide de la formation IA en entreprise) sert de boussole.
| Niveau | Description | Exemple cas d’usage | Risque opérationnel |
|---|---|---|---|
| N1 Chat ponctuel | Question / réponse manuelle, pas de continuité | Reformuler un email | Faible |
| N2 Assistant persistant | Assistant configuré, contexte stable, réutilisé | Synthèse hebdomadaire de réunions | Faible à modéré |
| N3 Workflow automatisé | Chaîne d’actions déclenchée par un événement, supervision humaine | Tri mails entrants → catégorie → réponse type | Modéré |
| N4 Agent autonome | Mission de haut niveau, l’agent décide des étapes | Veille concurrentielle hebdomadaire | Élevé, encadrement nécessaire |
La règle pratique : commencer un nouveau cas d’usage à N2 maximum, valider la qualité dans la durée, puis automatiser progressivement vers N3. N4 ne se légitime qu’après une expérience opérationnelle solide et un cadre de garde-fous (cf. guide agent IA en entreprise).
Cas d’usage 1 — Extraction documentaire
C’est le cas d’usage IA le plus répliqué en entreprise B2B en 2026. Le principe : transformer un document non structuré (PDF, facture scannée, contrat, formulaire) en données exploitables (CSV, JSON, entrée CRM ou ERP).
Pourquoi ça marche : la valeur est immédiatement quantifiable. Une saisie manuelle de facture prend typiquement 3 à 5 minutes ; une extraction IA bien calibrée fait le même travail en moins de 30 secondes, avec un taux d’erreur souvent inférieur à la saisie humaine sur volume.
Cas d’application :
- Cabinets comptables : extraction de factures fournisseurs vers le PGI
- Mutuelles, assurances santé : pré-saisie de remboursements à partir des factures de soins non normées
- Cabinets juridiques : extraction d’informations clés de contrats (parties, montants, échéances, juridiction)
- Bureaux d’études BTP : extraction de données techniques depuis des rapports historiques
- RH : extraction d’informations CV pour préqualification (sous garde-fous AI Act/RGPD)
Volumétrie type : 1 000 à 100 000 documents par mois.
Architecture-type : un grand modèle de langage capable d’analyser aussi des images (« multimodal ») + une instruction structurée qui exige une sortie au format JSON + une couche de validation (règles métier, cohérence des montants, contrôle de doublons) + journalisation des appels.
Ce qui peut foirer :
- L’IA « hallucine » parfois — elle invente avec aplomb des champs qu’elle croit lire (typique sur les codes acte, références internes). Toujours valider contre une nomenclature interne.
- Sans couche de validation, les erreurs passent inaperçues.
- Les PDF scannés de mauvaise qualité dégradent fortement la précision.
Garde-fous : revue humaine sur 5 à 10 % des sorties les premières semaines, OCR classique en amont du LLM pour les scans dégradés, seuil de confiance par champ avec bascule humaine en dessous, audit trail systématique.
Souveraineté : un modèle installé localement (Mistral, Qwen, ou modèle de vision dédié sur vos propres serveurs) est largement à portée pour ce cas d’usage. Voir notre guide automatisation factures par IA et notre guide extraction de factures hétérogènes.
Cas d’usage 2 — Classification et tri
Recevoir un flux entrant (mails, tickets, demandes) et le router automatiquement vers le bon traitement, le bon service, ou la bonne catégorie. C’est un cas d’usage proche de l’extraction, mais centré sur la décision de routage.
Pourquoi ça marche : tout flux entrant non structuré crée du temps administratif inutile. La classification IA absorbe cette friction sans dégrader la qualité, à condition d’être bien calibrée.
Cas d’application :
- Service client : tri des mails entrants par typologie (devis, plainte, support, demande commerciale) et routage vers la bonne file
- Juridique : tri de courriers entrants par nature (mise en demeure, demande de droits RGPD, contractualisation, simple correspondance)
- Mutuelles, assurances : tri d’envois adhérents (justificatifs, demandes de remboursement, courriers de résiliation)
- Helpdesk informatique : catégorisation de tickets par criticité, type d’incident, équipe responsable
- RH : pré-tri de CV par profil et adéquation à la fiche de poste (avec vigilance AIPD — voir IA et RGPD)
Volumétrie type : 5 000 à 500 000 messages par mois.
Architecture-type : un LLM + une taxonomie métier explicite (10 à 50 catégories selon le domaine) + un score de confiance produit par le modèle + un seuil en-dessous duquel un humain reprend la main + audit trail des classifications.
Ce qui peut foirer :
- Classifier sans score de confiance produit des erreurs invisibles à l’usage.
- Une taxonomie trop fine (plus de 50 catégories) dégrade la performance.
- La classification de mails contient typiquement des données personnelles.
Garde-fous : taxonomie verrouillée et versionnée, deux étages (grande catégorie d’abord, sous-catégorie ensuite), seuil de confiance avec bascule humaine, AIPD si décisions automatisées en découlent (article 22 RGPD).
Voir notre guide tri automatique des mails par IA et notre guide classification de mails par IA.
Cas d’usage 3 — Automatisation de rapports et synthèses
Transformer un corpus brut (transcript de réunion, ensemble de documents, dataset d’incidents) en livrable structuré et lisible. C’est l’usage où l’IA générative apporte le plus de valeur perçue, parce qu’elle remplace une tâche objectivement pénible.
Pourquoi ça marche : la rédaction structurée est un travail répétitif à forte valeur résiduelle. L’IA y excelle, à condition de cadrer fortement le format de sortie.
Cas d’application :
- Comptes rendus de réunion : audio → transcript → CR structuré (décisions, actions, points en suspens)
- Synthèses de veille : ensemble d’articles → résumé thématique avec sources hyperliées
- Reporting projet : ensemble de tickets / commits / mails → synthèse hebdomadaire
- Rapports BTP / ingénierie : données chantier brutes → rapport structuré avec sections normalisées
- Synthèses juridiques : corpus de jurisprudence → note de synthèse avec citations
Volumétrie type : variable, typiquement 100 à 10 000 livrables par mois selon la taille de l’organisation.
Architecture-type : ingestion multimodale (Whisper pour l’audio, LLM vision pour les PDF, parser structuré pour les sources tabulaires) + prompt système avec template strict de sortie + relecture par un second LLM ou par règles déterministes pour vérifier la complétude et l’absence d’hallucinations sur les chiffres.
Ce qui peut foirer :
- Les synthèses générées contiennent souvent des chiffres faux (additions inventées, pourcentages incorrects).
- Le ton de sortie dérive vers un ton générique.
- Les biographies, citations directes, références juridiques sont les terrains les plus risqués pour les hallucinations.
Garde-fous : toute donnée numérique recroisée avec la source primaire, exemples (few-shot) pour calibrer le ton attendu, validation humaine sur les livrables à enjeu (juridique, financier, communication externe).
Cas d’usage 4 — Agents autonomes encadrés
Donner à un système IA une mission de haut niveau et le laisser exécuter sans supervision continue. C’est le cas d’usage le plus prometteur et le moins mature en 2026.
Pourquoi c’est délicat : la promesse est intuitive (« fais ma veille hebdomadaire »), mais l’exécution réelle implique de coordonner recherche, lecture, hiérarchisation, action — chaque étape introduisant un risque d’erreur composé.
Cas d’application qui marchent en production :
- Veille concurrentielle structurée sur un périmètre défini (5-10 sources, fréquence hebdomadaire, format de sortie strict)
- Planification d’agenda : analyse d’une semaine, propositions de créneaux, blocage de plages, sous supervision finale
- Préparation de réunion : recueil automatique d’informations sur les participants, l’historique du dossier, les actions en cours
- Suivi d’incidents : surveillance d’un canal d’alertes, première qualification, escalade au bon humain
Cas d’usage à éviter en autonomie pure :
- Décisions à effet juridique sur des personnes (RH, scoring, accès)
- Communications externes non supervisées (mails clients, posts publics)
- Actions techniques irréversibles (déploiement, suppression, transactions financières)
Architecture-type : framework d’orchestration (LangGraph, n8n + LLM, Dify) + boucles de validation à chaque étape clé + journalisation détaillée + budget d’actions (limite explicite du nombre d’appels et de l’impact possible) + procédure d’arrêt d’urgence.
Ce qui peut foirer : agent qui « part en vrille » sur un raisonnement erroné, autonomie complète mal encadrée, frontière de responsabilité floue.
Garde-fous : budget maximum d’itérations, supervision humaine sur les étapes critiques, kill switch testé régulièrement.
Voir notre guide agent IA en entreprise pour le cadre complet.
Cas d’usage 5 — Anonymisation et reconnaissance d’entités nommées (NER)
Identifier et masquer (ou remplacer) les données personnelles dans un texte. C’est un cas d’usage IA souvent sous-estimé, alors qu’il déverrouille beaucoup d’autres usages — en rendant des données utilisables sans risque RGPD.
Pourquoi ça marche : la reconnaissance d’entités nommées est une des tâches que les modèles d’IA modernes maîtrisent le mieux. Combinée à un dictionnaire de remplacement, on obtient une chaîne de pseudonymisation efficace.
Cas d’application :
- Préparation de données pour entraînement IA : pseudonymiser un corpus client avant fine-tuning
- Mise à disposition pour analyse : permettre à un consultant ou un partenaire d’exploiter des données métier sans accès aux identifiants
- Conformité : préparer des extractions pour réponse à des demandes d’accès RGPD, ou pour répondre à des audits sans exposer plus que nécessaire
- Intelligence économique : analyser des corpus internes (notes, mails) à des fins managériales, sans surveillance individuelle illégale
- Recherche : ouvrir un dataset interne à un partenaire académique sous condition de pseudonymisation
Volumétrie type : 10 000 à 1 million de documents selon le projet.
Architecture-type : LLM NER multilingue (Mistral, modèles dédiés type spaCy ou GLiNER) + dictionnaire de remplacement (Marie Dupont → Personne_001) + journalisation réversible (clé de re-identification stockée séparément, sous accès strictement contrôlé) + audit du taux de rappel sur un corpus de validation.
Ce qui peut foirer :
- La pseudonymisation ne supprime pas la qualité de donnée personnelle au sens du RGPD si la clé de re-identification existe.
- Le NER manque souvent les données indirectement identifiantes (combinaisons rares, références internes, contextes singuliers).
- Le multilingue est un défi : un NER calibré sur du français standard rate les noms étrangers.
Garde-fous : revue humaine sur échantillon, tests de re-identification, modèle multilingue testé sur la langue cible, accès très restreint à la clé.
Voir notre guide anonymisation et NER par IA pour le détail technique et juridique.
Tableau de synthèse — quel cas démarrer en premier ?
| Cas d’usage | Maturité 2026 | Volumétrie utile | Risque RGPD | Bon premier cas ? |
|---|---|---|---|---|
| Extraction documentaire | Élevée | Élevée | Faible à modéré | Oui (si PDF stables) |
| Classification / tri | Élevée | Élevée | Modéré | Oui (si taxonomie claire) |
| Synthèses / rapports | Élevée | Variable | Faible | Oui (si format strict) |
| Agents autonomes | Moyenne | Faible à moyenne | Modéré à élevé | Non — pas en premier cas |
| Anonymisation / NER | Élevée | Élevée | Élevé (paradoxal) | Oui si projet aval clair |
Critères de sélection d’un cas d’usage IA
Tous les cas d’usage ne se valent pas. Pour un démarrage solide, cinq critères discriminants — l’absence de l’un d’eux est un drapeau rouge.
1. Volume et répétabilité. Plus la tâche est répétée, plus le ROI IA est facile à matérialiser. Une tâche occasionnelle reste plus efficace en humain. Seuil pratique : si la tâche est exécutée moins de 10 fois par mois, l’industrialisation IA est rarement justifiée.
2. Tolérance à l’erreur. Plus le coût d’une erreur est élevé, plus l’IA doit être encadrée. Distinguer : erreurs récupérables (un email mal classé qu’on retrouve), erreurs coûteuses (une facture mal extraite), erreurs catastrophiques (une décision RH automatisée biaisée). Démarrer sur les premières.
3. Disponibilité des données d’évaluation. Sans corpus d’évaluation (cas validés humainement), impossible de mesurer la qualité de l’IA. Si vous ne pouvez pas constituer 50 à 200 exemples annotés sur le cas d’usage, ce n’est pas le bon point de départ.
4. Sensibilité des données. Plus les données sont sensibles (santé, finance, RH), plus l’infrastructure doit être solide (on-premise ou cloud souverain), et plus la conformité doit être documentée. Démarrer sur des cas à sensibilité moyenne pour valider la méthode avant d’attaquer le sensible.
5. Soutien organisationnel. Un cas d’usage IA sans sponsor métier engagé échoue, quelle que soit la qualité technique. Le sponsor définit les critères de succès, valide les itérations, porte le déploiement auprès des utilisateurs.
Erreurs typiques en démarrage IA
Cinq pièges qui transforment un projet IA prometteur en initiative qui s’enlise.
Erreur 1 — Démarrer sans baseline humaine. On ne peut pas mesurer un gain IA sans connaître le coût humain de la tâche actuelle. Toujours mesurer en amont : temps moyen, taux d’erreur, charge mentale, satisfaction utilisateur.
Erreur 2 — Choisir la techno avant le cas d’usage. « On veut faire du RAG », « On veut un agent autonome », « On veut fine-tuner un modèle ». Ce ne sont pas des cas d’usage. Toujours partir d’un problème métier mesurable, puis sélectionner la bonne brique technique.
Erreur 3 — Sauter l’évaluation. Sans corpus de test annoté, impossible de comparer deux approches. C’est l’investissement le plus rentable du projet, et le plus souvent négligé.
Erreur 4 — Industrialiser un POC sans le retester. Un POC qui marche sur 20 cas se casse souvent à 200 — distribution des données différente, edge cases découverts en production. Prévoir une phase pilote avec monitoring avant le passage en production complète.
Erreur 5 — Sous-estimer le coût de la conformité. Une bonne implémentation IA prévoit dès la conception : registre de traitement, AIPD si nécessaire, supervision humaine sur décisions automatisées, journalisation, charte d’usage, formation des équipes. Ces briques ne sont pas optionnelles. Voir notre guide IA et RGPD pour le cadre complet.
Roadmap d’industrialisation d’un cas d’usage IA
Quatre phases à respecter. Sauter une phase, c’est garantir un retour en arrière.
Phase 1 — Cadrage (1 à 3 semaines) : description précise du cas d’usage, baseline humaine mesurée, critères de succès quantifiés, identification des données disponibles, AIPD préliminaire si données personnelles à risque.
Phase 2 — Pilote (4 à 8 semaines) : prototype technique, corpus d’évaluation annoté (50 à 200 exemples), itérations sur le prompt et l’architecture, mesure de la qualité contre la baseline. Choix du modèle final basé sur l’évaluation, pas sur les benchmarks publics.
Phase 3 — Déploiement supervisé (1 à 3 mois) : mise en production avec supervision humaine systématique, monitoring de la qualité en continu, ajustements, formation des utilisateurs, écriture de la documentation opérationnelle. KPIs : taux de réussite, taux de bascule humain, coût d’inférence, satisfaction utilisateur.
Phase 4 — Industrialisation (continu) : automatisation progressive, baisse du taux de supervision humaine selon les indicateurs, intégration dans les processus existants, plan de maintenance (mise à jour du modèle, re-évaluation périodique, audit qualité).
Schéma de la roadmap
[Cadrage 1-3 sem]
│
▼
[Pilote 4-8 sem] ──► corpus d'éval, choix modèle, prompt v1
│
▼
[Déploiement supervisé 1-3 mois] ──► monitoring continu, ajustements
│
▼
[Industrialisation continu] ──► réduction supervision, audits périodiques
│
▼
[Évolution substantielle ?] ──► retour cadrage / révision AIPD
Ce qu’on refuse de promettre
Trois antiPatterns récurrents qu’on évite chez DPLIANCE quand on conçoit une solution IA sur mesure.
« On va tout faire en 6 semaines, du cadrage à la production. » Sur un POC, peut-être. En production avec supervision, monitoring, conformité, intégration au SI : non. Promettre ce délai garantit un retour en arrière. Six mois est un délai réaliste pour un cas d’usage simple bien cadré ; neuf à douze mois pour un cas complexe.
« L’IA va remplacer cette équipe. » L’IA absorbe du volume répétitif, libère du temps humain, mais ne remplace pas la fonction relationnelle, la qualité d’écoute, le jugement contextuel. Les équipes qu’on a vu « remplacer » ont fini par perdre la qualité qui faisait leur valeur. La cible est l’augmentation, pas le remplacement.
« Le LLM SaaS américain suffit, c’est moins cher. » Ça dépend. Pour des données business non sensibles, oui. Pour des données personnelles à grande échelle, sensibles ou stratégiques, non — RGPD applicable, DPA nécessaire, transfer impact assessment, et risque résiduel non nul du Cloud Act. La stack souveraine ou on-premise n’est pas un luxe : c’est la conformité de base. Voir notre guide IA souveraine et notre guide LLM local en entreprise.
FAQ
Combien de temps faut-il pour mettre un cas d’usage IA en production ?
Un cas d’usage simple (extraction documentaire, classification de mails non sensibles) sur des données déjà disponibles peut atteindre la production en 2 à 4 mois en suivant la roadmap cadrage / pilote / déploiement supervisé / industrialisation. Un cas d’usage plus complexe (agent autonome, NER multilingue, intégration ERP avancée) prend généralement 4 à 9 mois. Les délais plus courts sont possibles uniquement quand la baseline humaine est déjà cartographiée et qu’un sponsor métier est engagé. Sauter une phase, c’est garantir un retour en arrière.
Quel budget prévoir pour un premier cas d’usage IA ?
Pour les phases 1-2 (cadrage + pilote) d’un POC industrialisable en entreprise B2B : entre 30 000 et 80 000 euros. Ce budget couvre l’analyse métier, la baseline humaine, le prototype, l’évaluation rigoureuse, et la définition de l’architecture cible. La phase d’industrialisation (3-4) est proportionnelle à la complexité d’intégration et au volume traité — elle peut doubler le coût initial selon les exigences de SI. Prévoir aussi 15-25 % du coût initial annuel en run (monitoring, mise à jour des prompts, audit qualité).
Faut-il un modèle fine-tuné ou un modèle générique suffit-il ?
Pour la plupart des cas d’usage métier en 2026, un modèle générique bien prompté (Mistral, Llama 3, Claude) suffit. Le fine-tuning n’est justifié que dans trois cas : précision insuffisante après itérations sur le prompt et la structure du contexte, volumes très importants où le coût d’inférence devient un facteur dimensionnant, besoin de spécialisation linguistique ou métier impossible à atteindre par prompt (terminologie médicale rare, jargon ultra-spécialisé). Démarrer toujours sans fine-tuning, basculer si l’évaluation le justifie.
Peut-on commencer un projet IA sans data scientist ?
Oui, à condition d’avoir une équipe développement à l’aise avec les API LLM et un sponsor métier engagé. Les cas d’usage extraction documentaire et classification se construisent largement par engineering de prompt et architecture logicielle classique. Un data scientist devient utile pour les phases d’évaluation rigoureuse (corpus de test, métriques), le fine-tuning, et les architectures avancées (RAG complexe, agents multi-étapes, NER multilingue). En 2026, beaucoup d’organisations démarrent sans data scientist et en recrutent un quand le portefeuille de cas d’usage le justifie.
Comment choisir entre Mistral, Llama, Claude, GPT-4 pour un cas d’usage ?
Trois critères. Un, la conformité — Mistral (souverain français/européen) et les modèles open-weight (Llama, Mistral, Qwen) déployés en interne offrent le meilleur cadre de souveraineté ; les modèles US en SaaS imposent un transfer impact assessment. Deux, la performance sur la tâche cible — à évaluer sur votre corpus d’évaluation, pas sur des benchmarks génériques. Trois, le coût d’inférence — peut varier de 1 à 50 selon le modèle et le volume. Bonne pratique : tester deux ou trois modèles sur un échantillon représentatif (50-100 cas) avant de figer le choix.
Comment mesurer le ROI d’un cas d’usage IA ?
Trois métriques structurantes. Gain de temps : différence en heures-homme entre la baseline humaine et le processus IA, sur un volume mensuel représentatif. Taux d’erreur : comparé à la baseline humaine, sur le même corpus de validation. Délai de livraison : temps écoulé entre l’arrivée de la donnée et le livrable final. Le ROI cumulé doit intégrer aussi les coûts cachés : supervision humaine résiduelle, maintenance des prompts, audits qualité, mise à jour du modèle, conformité (AIPD, registre, charte). Beaucoup de projets affichent un ROI positif en oubliant 30-40 % des coûts cachés.
Quel est le pire cas d’usage IA pour démarrer ?
Trois mauvais départs typiques. Un, un cas d’usage à très faible volumétrie (moins de 10 occurrences par mois) : le ROI ne peut pas se matérialiser, et l’IA reste plus coûteuse que l’humain. Deux, un cas d’usage avec décision automatisée à effet juridique sur des personnes (RH, scoring crédit, attribution de prestation) sans cadre RGPD/AI Act déjà en place — c’est techniquement faisable, juridiquement risqué tant que la conformité n’est pas montée. Trois, un cas d’usage sans baseline humaine mesurée : impossible de prouver un gain. Démarrer plutôt sur un cas à fort volume, faible criticité, baseline mesurable — typiquement extraction documentaire ou classification.
Sources : Règlement (UE) 2024/1689 (AI Act) ; CNIL — recommandations sur l’IA et le RGPD ; EDPB, opinion 28/2024 sur les modèles d’IA et le RGPD ; documentation officielle Mistral AI, LangGraph, n8n, Dify ; jurisprudence Garante (Italie) sur l’inexactitude des contenus générés ; rapport Bothorel sur la donnée publique.
Pour cadrer un projet IA dans votre organisation — diagnostic, choix d’architecture, conformité — voir notre guide de l’IA souveraine, notre guide IA et RGPD, notre guide agent IA en entreprise, ou contactez-nous via nos solutions IA sur mesure.