Cas clients : intégration IA en production chez des PME françaises (Esteka Data, Fondation AnBer)
Deux cas clients réels d'intégration IA Developr : Esteka Data (extraction automatique de données) et Fondation AnBer (chatbot documentaire). Budgets, délais et résultats mesurés.
Ces cas clients Developr illustrent ce que l'intégration IA en entreprise produit concrètement, avec des chiffres vérifiables. Les détails confidentiels (chiffre d'affaires, noms de collaborateurs, contenu des documents internes) sont omis en accord avec les clients. Toutes les métriques présentées sont issues de mesures effectuées sur des périodes de production réelles, pas d'estimations préalables.
Cas 1 : Esteka Data — Extraction automatique de données depuis des rapports PDF non structurés
Contexte
Esteka Data est une société de conseil en données basée à Lille qui accompagne des entreprises industrielles dans la structuration de leurs données opérationnelles. Esteka Data reçoit chaque mois plusieurs centaines de rapports d'inspection et de maintenance au format PDF, produits par des prestataires extérieurs selon des formats hétérogènes. Ces rapports contiennent des données critiques (dates d'intervention, composants inspectés, anomalies détectées, actions correctives recommandées) que les équipes devaient saisir manuellement dans leur base de données centrale.
Problème
La saisie manuelle représentait 35 à 40 heures de travail par mois pour deux assistants dédiés. Le taux d'erreur de saisie atteignait 4 à 6 %, générant des litiges réguliers avec les clients industriels sur des données incorrectes. La volumétrie était par ailleurs en croissance : +30 % de rapports reçus sur les 18 mois précédant le projet, sans possibilité d'absorber cette croissance par du recrutement.
Solution implémentée
Developr a développé un pipeline d'extraction IA en trois étapes intégré à l'application Laravel existante d'Esteka Data.
Étape 1 : extraction du texte des PDF. Une étape de pre-processing extrait le texte des PDF (y compris les PDF scannés via OCR avec Tesseract) avant de l'envoyer au modèle.
Étape 2 : extraction structurée via GPT-4o. Un prompt system précis demande au modèle d'extraire les champs définis (date, prestataire, site, composants inspectés, anomalies, statut) et de renvoyer un objet JSON structuré. GPT-4o a été choisi plutôt que GPT-4o mini en raison de la variabilité des formats de rapports : certains documents présentent des tableaux complexes et des abréviations métier qui nécessitaient la capacité de compréhension nuancée de GPT-4o.
Étape 3 : validation humaine assistée. Plutôt que d'écrire directement en base de données, le pipeline présente à l'opérateur une interface de validation qui affiche les données extraites en regard du PDF source, avec mise en évidence des passages d'où chaque donnée a été extraite. L'opérateur valide, corrige ou rejette chaque extraction en quelques secondes.
Stack technique : PHP 8.2 / Laravel 11, API OpenAI GPT-4o, Tesseract OCR, interface de validation en Vue.js 3, stockage PostgreSQL.
Résultats mesurés (6 mois de production)
- Temps de traitement par rapport : réduit de 18 minutes (saisie manuelle) à 45 secondes (validation assistée), soit une réduction de 96 %.
- Volume traité : 1 840 rapports traités sur les 6 premiers mois, soit une capacité multipliée par 3 par rapport à l'équipe manuelle sur la même période.
- Taux d'erreur : 0,8 % sur les champs numériques critiques (contre 4 à 6 % en saisie manuelle). Les erreurs résiduelles concernent principalement les abréviations non documentées de prestataires spécifiques.
- Coût d'exploitation mensuel : 85 euros de tokens API (GPT-4o) pour un traitement moyen de 300 rapports par mois.
- Budget de développement : 14 500 euros (audit 3 jours, développement 6 semaines, tests 2 semaines).
- ROI : les 30 heures de travail économisées mensuellement représentent un coût évité de 1 200 euros par mois. Le seuil de rentabilité a été atteint en 12 mois.
Enseignements généralisables
La validation humaine assistée est préférable à la saisie automatique directe pour les projets d'extraction de données critiques. Elle maintient l'humain dans la boucle de contrôle, réduit les erreurs d'un facteur 5 à 8 par rapport à la saisie manuelle seule, et génère un dataset de corrections qui permet d'améliorer les prompts au fil du temps. Un opérateur formé valide 50 à 60 extractions par heure avec ce système, contre 3 à 4 saisies manuelles complètes.
Cas 2 : Fondation AnBer — Chatbot documentaire pour les bénéficiaires
Contexte
La Fondation AnBer est une fondation d'utilité publique qui accompagne des personnes en situation de handicap en France. La fondation gère une documentation interne volumineuse : procédures d'accompagnement, droits et démarches administratives, ressources pédagogiques, guides par type de handicap. Les équipes d'accompagnement et les familles de bénéficiaires posent régulièrement des questions auxquelles les conseillers répondaient en cherchant manuellement dans cette documentation.
Problème
Les conseillers passaient en moyenne 25 minutes par question complexe à localiser l'information dans la documentation (dispersée sur un SharePoint mal organisé, des PDF téléchargeables et un wiki interne). 40 % des questions entrantes portaient sur les mêmes 30 à 40 démarches administratives récurrentes. La charge de ces questions répétitives mobilisait 2 équivalents temps plein, détournant des ressources de l'accompagnement humain à forte valeur ajoutée.
Solution implémentée
Developr a développé un assistant documentaire IA accessible via une interface web intégrée à l'intranet de la Fondation AnBer, et via une interface simplifiée accessible aux familles de bénéficiaires.
Architecture RAG. L'ensemble de la documentation de la fondation (1 200 documents, soit environ 850 000 tokens de texte) a été ingérée, découpée en chunks de 800 tokens avec overlap de 100 tokens, et vectorisée avec les embeddings OpenAI text-embedding-3-small. Les vecteurs sont stockés dans PostgreSQL via l'extension pgvector.
Système de réponse. Quand une question est posée, le système récupère les 5 passages les plus proches sémantiquement de la question, les injecte dans un prompt system qui demande au modèle de répondre exclusivement à partir des passages fournis, en citant la source (nom du document et section). Si aucun passage pertinent n'est trouvé, le modèle répond qu'il ne dispose pas de l'information et suggère de contacter un conseiller.
Modèle choisi : GPT-4o mini. Les questions portant sur des procédures administratives ne nécessitent pas les capacités de raisonnement avancées de GPT-4o. GPT-4o mini offre des performances suffisantes à un coût 20 fois inférieur.
Stack technique : Node.js / Express, PostgreSQL + pgvector, OpenAI API (embeddings + GPT-4o mini), interface React, authentification SSO via l'Active Directory de la fondation.
Résultats mesurés (4 mois de production)
- Volume de questions traitées : 2 400 questions sur les 4 premiers mois (environ 600 par mois), dont 78 % ont reçu une réponse directe sans escalade vers un conseiller.
- Temps de réponse moyen : 2,8 secondes (contre 25 minutes en recherche manuelle pour les questions complexes).
- Taux de satisfaction des utilisateurs (conseillers) : 87 % de réponses jugées "correctes ou très correctes" lors de l'évaluation mensuelle sur un échantillon de 50 questions.
- Escalades vers un conseiller : 22 % des questions, dont la moitié était accompagnée d'un résumé du contexte généré par le chatbot (réduisant le temps de traitement du conseiller de 40 %).
- Coût d'exploitation mensuel : 12 euros de tokens API (GPT-4o mini) + 3 euros pour les embeddings.
- Budget de développement : 22 000 euros (audit documentaire 5 jours, développement 8 semaines, tests avec les conseillers 3 semaines).
- ROI : la libération de 30 % du temps des 2 ETP conseillers dédiés aux questions documentaires représente 8 000 euros de valeur mensuelle réallouée à l'accompagnement humain. Seuil de rentabilité atteint en 3 mois.
Enseignements généralisables
La qualité de la segmentation documentaire (chunking) conditionne 50 % de la qualité des réponses d'un système RAG. Des chunks trop courts perdent le contexte nécessaire à une réponse complète. Des chunks trop longs saturent le contexte disponible et réduisent la précision de la recherche vectorielle. La taille de 800 tokens avec overlap est un point de départ solide, à affiner selon la structure des documents de votre domaine.
La transparence sur les sources (citation du document et de la section d'où vient la réponse) augmente significativement la confiance des utilisateurs et réduit le taux de rejet des réponses correctes. Les utilisateurs qui peuvent vérifier la source acceptent mieux une réponse IA que ceux qui reçoivent une réponse sans référence.
Ce que ces deux projets ont en commun
Kevin Indig, auteur de la newsletter Growth Memo et expert en croissance digitale, observe que les projets d'intégration IA qui réussissent en PME partagent trois caractéristiques : un cas d'usage précis avec un résultat mesurable défini avant le démarrage, un humain dans la boucle de validation plutôt qu'une automatisation totale, et une phase de test avec des données réelles avant la mise en production.
Les deux projets Developr présentés ici vérifient ces trois critères. Dans les deux cas, le premier mois de production a révélé des catégories de documents ou de questions que les prompts initiaux ne traitaient pas bien. L'amélioration continue des prompts — sur la base des logs de production — représente 80 % du travail de maintenance post-déploiement.
Pour démarrer votre propre projet d'intégration IA, contactez Developr pour un audit de faisabilité de 2 à 3 jours qui définit le cas d'usage prioritaire, l'architecture et le budget avant tout engagement.
FAQ
Les données des clients Esteka Data et Fondation AnBer sont-elles envoyées à OpenAI ?
Oui, les textes des rapports et des documents sont envoyés à l'API OpenAI pour traitement. Dans les deux cas, un DPA (Data Processing Agreement) a été signé avec OpenAI avant le démarrage. Les données des clients d'Esteka Data sont des données industrielles non personnelles. Pour la Fondation AnBer, les questions des utilisateurs ne contiennent pas de données personnelles identifiantes (les noms de bénéficiaires ne sont jamais inclus dans les prompts). Une analyse légale d'une demi-journée avec un avocat spécialisé a précédé le démarrage des deux projets.
Ces projets sont-ils reproductibles pour une PME de secteur différent ?
Oui. Le pipeline d'extraction de données (cas Esteka Data) est applicable à tout contexte où des documents semi-structurés doivent être transformés en données exploitables : factures fournisseurs, rapports d'expertise, formulaires clients, comptes-rendus de réunion. Le système RAG (cas Fondation AnBer) est applicable à toute organisation disposant d'une base documentaire interne volumineuse.
Quel est le délai réaliste entre le premier contact et la mise en production ?
Pour les deux projets présentés : 11 semaines (Esteka Data) et 16 semaines (Fondation AnBer) du premier contact à la mise en production. Ces délais incluent la phase d'audit, le développement, les tests avec les utilisateurs finaux et le déploiement progressif. Un projet plus simple (un seul cas d'usage, une stack moderne bien documentée) peut être mis en production en 4 à 6 semaines.