IA et productivité : les vrais gains, les chiffres 2024-2026 et la méthode sans bullshit

L'intelligence artificielle est devenue facile à tester. Cela ne veut pas dire qu'elle produit automatiquement un gain pour l'entreprise. Pour une TPE ou une PME, le vrai sujet n'est pas de savoir combien d'outils sont disponibles, mais quelle tâche devient plus rapide, plus fiable ou plus simple à contrôler. Le calculateur de gains IA aide à estimer ce temps libéré avant de le mesurer sur un cas réel.

Adoption forte, ROI à démontrer : que disent les enquêtes ?

En 2024, 78 % des répondants de l'enquête McKinsey déclaraient que leur organisation utilisait l'IA dans au moins une fonction, contre 55 % un an plus tôt. Pourtant, seuls 6 % des répondants de l'édition 2026 se classent parmi les organisations qui attribuent au moins 5 % d'EBIT à l'IA et déclarent en tirer une valeur significative. Le constat est simple : l'adoption est un signal d'intérêt, pas une preuve de rentabilité. Lire l'analyse McKinsey.

Le rapport MIT NANDA sur le GenAI Divide rapporte de son côté qu'environ 95 % des initiatives étudiées n'avaient pas produit d'impact mesurable sur le compte de résultat. Ce chiffre décrit un échantillon et une définition précise de la valeur. Il ne signifie pas que toute utilisation de l'IA est inutile. Il montre surtout qu'un pilote sans indicateur, propriétaire et décision d'arrêt reste une démonstration.

Lecture : ces chiffres décrivent des enquêtes et des échantillons différents. Ils ne constituent pas une promesse de résultat pour votre entreprise.

1. Pourquoi l'adoption ne remonte pas automatiquement au chiffre d'affaires

Une IA peut faire gagner quelques minutes sur une tâche tout en laissant le processus global inchangé. Si le document généré est relu intégralement, si la donnée doit être recopiée dans un autre outil ou si personne ne sait quoi faire ensuite, le gain local disparaît.

McKinsey précise d'ailleurs que la définition de l'adoption couvre des situations très différentes, de l'expérimentation par quelques salariés à l'intégration dans plusieurs fonctions. Comparer une entreprise qui teste un assistant de rédaction avec une entreprise qui a refondu son parcours de vente n'a donc pas beaucoup de sens.

Le rapport MIT NANDA arrive à une conclusion complémentaire : les projets qui atteignent la production sont plus souvent reliés à un processus métier réel, à une source de données exploitable et à une boucle de retour. Un chatbot isolé peut être apprécié par ses utilisateurs sans produire une économie traçable. Un flux simple, branché sur le bon outil et suivi par une personne identifiée, a davantage de chances d'être évalué correctement.

Avant de parler de modèle ou d'abonnement, écrivez la chaîne complète : entrée, préparation, génération, vérification, envoi et suite donnée. C'est cette chaîne qu'il faut améliorer. Notre méthode d'automatisation IA commence par ce cadrage plutôt que par une liste d'outils.

2. Combien de temps l'IA fait-elle réellement gagner ?

Les données récentes de la Banque centrale européenne donnent un repère utile. Son enquête mensuelle auprès d'environ 20 000 personnes dans 11 pays de la zone euro indique qu'en 2026, 52 % des répondants utilisent l'IA dans leur travail. Parmi les utilisateurs, le temps économisé médian déclaré est de trois heures par semaine, soit environ 7,7 % du temps de travail médian. Consulter l'analyse de la BCE.

Ce résultat doit être lu avec trois précautions. D'abord, il s'agit de temps déclaré par les travailleurs, pas d'une mesure universelle de productivité. Ensuite, le gain dépend fortement de la tâche : la BCE observe des économies plus importantes pour le code, l'analyse de données ou l'automatisation de tâches routinières que pour la recherche ou la rédaction. Enfin, une heure libérée ne devient une performance économique que si l'entreprise la réinvestit dans du travail utile.

Pour votre propre mesure, distinguez au moins quatre temps : préparation, production avec l'IA, vérification et reprise. Notez aussi le volume traité, les erreurs détectées et les cas envoyés à un humain. Un tableau simple sur deux semaines vaut mieux qu'une estimation faite après une démonstration.

3. Le piège du ressenti : plus rapide dans sa tête, plus lent dans le flux

Le développement logiciel fournit un exemple particulièrement instructif. Dans un essai randomisé publié par METR en 2025, 16 développeurs expérimentés ont travaillé sur 246 tâches réelles de leurs propres dépôts open source. Ils pensaient gagner du temps avec les outils disponibles, mais les tâches ont finalement pris 19 % plus longtemps lorsque l'IA était autorisée dans ce contexte précis. Après l'expérience, ils estimaient pourtant avoir été 20 % plus rapides. Voir la méthodologie METR.

Ce résultat ne dit pas que l'IA ralentit tous les développeurs. METR précise que l'étude porte sur un environnement, des outils et des professionnels particuliers. Elle montre en revanche pourquoi le ressenti ne suffit pas : l'IA réduit la friction de départ, mais peut ajouter de la relecture, des corrections, des tests et des allers-retours de contexte.

Le rapport DORA 2024 de Google Cloud aboutit à une nuance proche dans la livraison logicielle : l'adoption de l'IA est associée à une baisse estimée de 1,5 % du débit de livraison et de 7,2 % de sa stabilité, alors que plusieurs facteurs individuels progressent. Lire les résultats DORA. Une équipe peut donc produire davantage de brouillons tout en livrant moins bien si ses tests, ses lots de travail ou ses règles de revue ne suivent pas.

Leçon pratique : mesurez le temps jusqu'au résultat accepté, pas le temps passé à obtenir une première réponse.

4. Les tâches où l'IA a le meilleur rapport utilité, contrôle et complexité

Chez Leka Digital, nous recommandons de commencer par la substitution d'une étape répétitive, pas par la transformation complète d'un métier. Les bons candidats ont une entrée identifiable, une sortie vérifiable et un coût d'erreur limité.

Les usages généralement testables

• Transcription et synthèse de réunion : produire un compte rendu structuré avec décisions, actions, responsable et échéance, puis vérifier les noms et les dates.
• Tri et préparation d'emails : classer les demandes, résumer un fil et préparer un brouillon sans envoi automatique.
• Recherche dans des documents internes : retrouver une procédure ou une information dans un espace limité, avec la source affichée.
• Code répétitif et documentation : générer un squelette, une documentation ou des tests, à condition de relire et d'exécuter les contrôles.
• Extraction de données : transformer un document semi-structuré en champs vérifiables, sans inventer les informations absentes.

Les tâches de stratégie, de négociation complexe, de relation client sensible, de validation juridique ou d'engagement financier sont d'une autre nature. L'IA peut préparer des options ou une synthèse, mais la décision et la responsabilité restent humaines.

La matrice aide à choisir un premier test. Elle ne classe pas définitivement un métier ni un outil.

5. La méthode Leka en trois étapes pour calculer un ROI réel

Étape 1 : mesurer la situation sans IA

Choisissez une seule tâche réalisée plusieurs fois par semaine. Pendant deux semaines, notez le nombre de cas, le temps de préparation, le temps de vérification, les erreurs et le délai jusqu'à la sortie acceptée. Ne modifiez pas encore le processus : vous cherchez une baseline comparable.

Pour une TPE, un compte rendu de réunion, une relance préparée ou le classement de demandes entrantes sont souvent plus adaptés qu'un agent relié à tous les outils. Le premier test doit être fréquent, réversible et compréhensible par la personne qui fait le travail.

Étape 2 : tester un outil et un prompt modèle

Limitez le test à un outil, deux personnes et un jeu de cas représentatif. Écrivez un prompt stable qui demande à l'IA de ne pas compléter les informations absentes :

Voici le transcript brut. Produis un compte rendu avec quatre rubriques : décisions, actions avec responsable, échéances et questions ouvertes. N'invente aucune information. Si un élément manque, écris [MANQUANT]. Signale les passages ambigus à vérifier.

Conservez les entrées, les sorties et les corrections. Le but n'est pas d'obtenir la réponse la plus impressionnante, mais de voir si le même protocole reste utile sur des cas normaux et des cas incomplets.

Étape 3 : comparer le coût complet

Utilisez cette formule : ROI opérationnel = (temps avant - temps après vérification) × coût horaire chargé - coût de l'outil et de sa maintenance. Ajoutez le coût des erreurs, des reprises et des intégrations lorsque ces éléments sont significatifs.

Fixez une règle de décision avant le test. Par exemple : continuer si le gain net est positif, si la qualité reste au niveau attendu et si les personnes utilisent effectivement le flux ; corriger si la sortie est utile mais trop instable ; arrêter si la relecture annule le gain ou si le risque devient disproportionné.

6. Choisir une stack sans empiler les licences

Un outil généraliste peut suffire pour écrire, résumer ou traduire. Un outil intégré au métier est pertinent lorsque les données, les permissions et la sortie sont déjà bien définies. Une automatisation no-code devient intéressante seulement lorsque la tâche manuelle est stable et que les exceptions sont connues.

Ne comparez pas uniquement le prix affiché. Regardez l'espace de travail partagé, la gestion des accès, la politique d'utilisation des données, les journaux, l'export et la possibilité de revenir à un traitement manuel. Pour des données confidentielles ou personnelles, vérifiez le contrat, le rôle du fournisseur, la conservation et les conditions de réutilisation avant de brancher l'outil.

La règle la plus économique est souvent la suivante : un cas d'usage, un espace de travail approuvé, un responsable et une date de revue. Dix licences achetées avant la mesure ne constituent pas une stratégie. Elles peuvent simplement déplacer la dépense vers un usage invisible.

7. La check-list anti-bullshit avant d'acheter

• Avons-nous mesuré la tâche pendant deux semaines sans IA ?
• Le résultat attendu est-il défini par un critère observable ?
• Les données utilisées sont-elles autorisées et minimisées ?
• Une personne vérifie-t-elle les sorties avant un envoi ou une décision ?
• Le prompt ou le protocole a-t-il été testé sur des cas incomplets ?
• Savons-nous qui corrige, qui surveille et qui peut arrêter le flux ?
• Avons-nous fixé une date de revue et une règle d'arrêt ?

Pour les contrats, devis, données de santé, décisions RH, informations financières ou secrets commerciaux, ajoutez une validation adaptée au risque. Une IA peut préparer une analyse ; elle ne doit pas devenir l'autorité implicite du processus.

Une méthode adaptée aux TPE de Seine-et-Marne, du 93 et du 94

Le besoin est local, mais la méthode reste la même : partir d'une tâche réellement répétée par l'équipe. Un artisan peut commencer par structurer des notes de visite et préparer un compte rendu. Une agence peut classer les demandes et retrouver ses références. Un cabinet peut standardiser la préparation d'une réunion sans automatiser la décision du client.

Nous intervenons notamment à Meaux, Chelles, Marne-la-Vallée, Melun, Saint-Denis, Montreuil, Aubervilliers, Créteil et Vincennes. La présence locale ne change pas la mesure : elle permet surtout de travailler avec les documents, outils et contraintes de l'entreprise, sur un périmètre qui reste vérifiable. Demander un diagnostic digital et IA permet de cartographier trois tâches avant de choisir une licence.

Sources

Limites : les chiffres cités correspondent aux périmètres et méthodes des sources liées, souvent déclaratifs ou limités à un échantillon. Ils ne constituent pas une promesse de gain pour une entreprise donnée.

• McKinsey, The state of AI: How organizations are rewiring to capture value : taux d'adoption déclarés et part des organisations qui attribuent une valeur significative à l'IA.
• Banque centrale européenne, AI adoption and the productivity promise : usage de l'IA au travail dans la zone euro et temps économisé médian déclaré.
• METR, Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity : écart entre gain perçu et temps mesuré chez des développeurs expérimentés.