Comment identifier les problèmes métier que l'IA devrait vraiment résoudre

La plupart des projets d'IA sont cadrés à l'envers. Un modèle ou un framework d'agents arrive d'abord, et la recherche d'un usage commence ensuite. L'ordre est confortable, car une capacité se démontre facilement et un problème métier non.

Il explique aussi pourquoi les résultats publiés semblent se contredire. L'adoption de l'IA progresse bien plus vite que son impact financier mesuré, et la même technologie produit des gains importants sur une tâche et de moins bonnes réponses sur la suivante. Aucun de ces constats n'est un verdict sur l'IA. Tous deux parlent d'adéquation.

L'adoption progresse plus vite que l'impact

En 2025, 20% des entreprises de l'UE comptant au moins 10 salariés utilisaient des technologies d'IA, contre 13,5% un an plus tôt, selon Eurostat. L'analyse de la langue écrite était l'usage le plus fréquent.

L'impact financier ne suit pas au même rythme. Dans l'enquête « The State of AI 2026 » de McKinsey, 37% des répondants attribuaient un effet quelconque sur le résultat d'exploitation à l'IA, et environ 6% se qualifiaient parmi ce que McKinsey appelle les entreprises très performantes. Près de 20% déclaraient que les coûts d'exploitation liés à l'IA limitaient déjà leur usage de la technologie.

Au niveau des tâches, le constat est tout aussi partagé. Une étude de terrain portant sur 5 172 agents du service client, publiée dans le Quarterly Journal of Economics, montre qu'un assistant d'IA générative a augmenté de 15% en moyenne le nombre de dossiers résolus par heure, les gains les plus élevés allant aux collaborateurs les moins expérimentés (Brynjolfsson, Li et Raymond). Une expérience de terrain menée auprès de 758 consultants, publiée dans Organization Science, montre que sur des tâches situées à l'intérieur de la frontière de compétence du modèle, les participants réalisaient 12,2% de travail en plus et allaient 25,1% plus vite. Sur une tâche délibérément choisie au-delà de cette frontière, ces mêmes participants avaient 19% de chances en moins de parvenir à la bonne réponse (Dell'Acqua et ses collègues).

Lues ensemble, ces données disent plus que chacune prise séparément.

Lesquels de nos problèmes créent assez de valeur mesurable, présentent les bonnes caractéristiques de tâche et les bonnes données, et tolèrent une réponse probabiliste mieux qu'un logiciel ordinaire ?

Une capacité n'est pas un cas d'usage

« Résumer » est une capacité. « Réduire le temps que les chargés de clientèle passent à transformer leurs rendez-vous en fiches CRM, en conservant les champs obligatoires et une validation avant enregistrement » est un cas d'usage.

La différence, c'est que le second peut être analysé. Il a un processus, un volume, un coût, un responsable et une définition de ce qui est terminé. « Déployer un LLM », « utiliser des agents » et « introduire l'IA générative dans l'entreprise » n'ont rien de tout cela, et c'est précisément pourquoi on ne peut ni les évaluer, ni les financer, ni les refuser sur la base de preuves.

Un énoncé de problème exploitable comporte quatre éléments : l'état actuel, une douleur mesurable, le processus concerné et le résultat visé. Par exemple : notre service financier traite des factures fournisseurs arrivant dans des centaines de mises en page, ce qui crée deux jours de retard et beaucoup de traitement d'exceptions, et nous voulons réduire le temps de traitement et les interventions manuelles sans affaiblir le contrôle financier.

Avant toute discussion technique, notez l'objectif métier, le responsable du processus, le flux actuel, le volume et la fréquence des transactions, le temps de cycle, le coût de main-d'œuvre chargé, les reprises et taux d'erreur, le coût d'une erreur, les systèmes concernés, les données existantes, leur classification de sécurité, les contraintes réglementaires, le jugement que le travail exige réellement et les indicateurs de référence. C'est le contexte métier de l'IA, et c'est lui qui transforme une initiative en quelque chose qu'un ingénieur peut dimensionner.

Cartographier le processus avant de l'automatiser

Une grande partie des projets qui échouent automatisent la tâche visible sans examiner le processus autour d'elle. Cartographiez le travail sous la forme entrée, activité, décision, transmission, système, exception, résultat. Cherchez ensuite où le travail s'accumule, quelles étapes créent des reprises, où l'information est saisie deux fois, quelles décisions reposent sur un savoir que personne n'a écrit, où les personnes déplacent des données à la main entre systèmes, quelles validations n'apportent aucun contrôle et quelles exceptions absorbent l'essentiel de l'effort.

Ce que cela révèle, en général, c'est que le candidat à l'automatisation n'est pas le goulot d'étranglement.

Si une facture attend trois jours parce qu'elle exige cinq validations, l'acheminer automatiquement à travers les mêmes cinq validations déplace la file d'attente au lieu de la supprimer. Si des personnes recopient six champs connus entre deux systèmes, une intégration par API est plus fiable qu'un agent. Si un assistant interne ne trouve pas de réponse parce que la documentation est périmée, un meilleur modèle ne corrigera pas la documentation. Parfois le projet d'IA le plus rentable est un changement de processus sans IA.

Quatre situations qui se ressemblent

Les demandes qui sonnent pareil en comité de pilotage relèvent en général de quatre problèmes différents, et chacun appelle un premier geste différent.

Le logiciel ordinaire doit rester le choix par défaut chaque fois que la bonne réponse peut être spécifiée exactement : calculs, validations déterministes, droits d'accès, règles d'éligibilité, opérations en base, traitements planifiés, transitions d'état, formules fiscales et tarifaires. Si un ingénieur peut définir le résultat correct dans du code, un modèle probabiliste ajoute surtout de l'incertitude.

L'IA mérite sa place quand la variabilité est la partie difficile. Documents non structurés, langage naturel, parole et images, classification, extraction, recherche sémantique, prédiction, détection d'anomalies, recommandation, génération, entrées incohérentes, et flux comportant trop de variantes pour être exprimés en arbre de règles. Même dans ce cas, le processus entier a rarement besoin d'IA. L'architecture qui tient est généralement l'IA pour l'étape ambiguë et du logiciel déterministe pour les étapes contrôlées.

La frontière traverse votre propre travail

L'expérience menée auprès des 758 consultants est le résultat le plus utile en pratique dans ce domaine, à cause de ce qu'il dit du niveau d'analyse. Deux activités peuvent sembler d'égale difficulté pour une personne et être totalement différentes pour un modèle. Cette frontière irrégulière ne suit ni les intitulés de poste, ni l'ancienneté, ni les services. Elle traverse les tâches une par une.

La question à poser est donc de savoir si l'IA peut accomplir cette tâche précise, pour ces utilisateurs, sur nos données, à une qualité et un coût acceptables. Et non si le dernier modèle est capable en général. Une tâche mérite un test lorsqu'elle est assez fréquente pour que les gains se cumulent, assez coûteuse pour compter, mesurable, assez variable pour que les règles peinent, alimentée par une information que le système peut atteindre, et produit un résultat que quelqu'un peut vérifier. Si une erreur ne peut pas être détectée, cette dernière condition tombe et le reste n'a plus d'importance.

Les données sont la vraie contrainte

Gartner a interrogé 1 203 responsables de la gestion des données : 63% n'avaient pas les pratiques de gestion de données nécessaires à l'IA ou ne savaient pas s'ils les avaient. Gartner prévoit également que d'ici 2026 les organisations abandonneront 60% des projets d'IA non soutenus par des données prêtes pour l'IA. Ce second chiffre est une prévision d'analyste et non un taux observé ; il décrit la dépendance, pas une proportion mesurée.

Ce que « données prêtes » signifie varie selon le cas d'usage. Un modèle prédictif a besoin d'observations historiques, de résultats représentatifs, d'étiquettes fiables, d'assez d'exemples d'événements rares et d'une certaine stabilité entre le passé et l'avenir. Le traitement documentaire a besoin de documents représentatifs, des champs attendus, des cas limites, d'une structure de sortie connue et de règles de validation. Un assistant de connaissance a besoin de sources faisant autorité, de droits d'accès qui tiennent, de métadonnées utiles, de processus de mise à jour et de suppression, et d'un jeu de questions d'évaluation. Un agent a besoin de plus que des documents : un accès fiable au CRM, à l'ERP, à la billetterie, aux bases de données, à la gestion des identités, aux API internes et aux règles métier elles-mêmes.

Pour chaque candidat, déterminez si les données sont disponibles, à jour, représentatives et utilisables licitement, à qui elles appartiennent, si les droits d'accès survivent à l'intégration, et si un jeu d'évaluation peut en être constitué. Là où les réponses manquent, le premier investissement est l'ingénierie des données, pas l'IA.

Des heures gagnées ne sont pas des économies

Un problème techniquement faisable peut rester économiquement sans intérêt. Estimez le volume annuel, le temps de traitement moyen, le coût de main-d'œuvre chargé, les reprises, le traitement des exceptions, les pertes liées aux erreurs, le coût des délais, le chiffre d'affaires perdu et le coût des outils actuels, et calculez seulement ensuite la valeur réellement récupérable.

Une erreur revient assez souvent pour être nommée. Les heures gagnées ne sont pas de l'argent. Si un assistant libère dix heures par semaine et que cette capacité n'est ni supprimée ni réaffectée, l'organisation a créé du mou, pas de la trésorerie. La valeur apparaît quand la capacité absorbe plus de volume, améliore le service, supprime des heures supplémentaires, remplace une dépense externe, raccourcit les cycles d'encaissement ou permet un travail à plus forte valeur. Décidez lequel de ces mécanismes s'appliquera avant que quelqu'un n'inscrive un retour sur investissement dans un dossier.

Ce que coûte une erreur

La précision moyenne est un mauvais critère de décision à elle seule. Un système décrit comme « précis à 95% » peut être excellent ou inutilisable selon la nature des 5% restants. Quatre questions tranchent : que se passe-t-il quand il se trompe, l'erreur peut-elle être détectée, peut-elle être annulée, et que coûte la vérification ?

Un brouillon interne erroné que quelqu'un relit avant envoi n'appartient pas à la même catégorie qu'une candidature rejetée, un paiement exécuté, une ligne de production arrêtée ou une recommandation médicale. La supervision humaine doit être proportionnelle à l'incertitude et aux conséquences, ce qui n'est pas la même chose que valider tout.

Une note d'opportunité utilisable

Pour que la priorisation soit reproductible et non politique, tous les candidats doivent être notés selon les mêmes critères. Le modèle ci-dessous est le nôtre, conçu pour un tri pratique entre services. C'est une heuristique de comparaison, pas un prédicteur validé de succès.

Quatre conditions viennent d'abord, et un candidat qui échoue à l'une d'elles n'est pas noté, il est corrigé. Y a-t-il un résultat mesurable ? Des données représentatives, fiables et licites sont-elles accessibles ? Les erreurs peuvent-elles être détectées, revues, contenues ou annulées à un degré acceptable ? Et l'IA offre-t-elle un avantage réel sur un logiciel plus simple ou un changement de processus ?

Les candidats qui franchissent ces conditions sont notés de 1 à 5 sur dix dimensions, chacune avec un poids propre. La note sur 100 est la somme des note ÷ 5 × poids.

Lire la note

Au-dessus de 80, le candidat est solide pour un pilote. Entre 65 et 79, il est prometteur dès que la principale incertitude a été testée. Entre 50 et 64, les fondations doivent d'abord être renforcées, et en dessous de 50, mieux vaut reporter ou résoudre autrement. Ces plages sont des seuils de priorisation, pas des probabilités de réussite.

Un flux de factures à mises en page variables notant 5 en valeur métier, en adéquation de tâche et en fréquence, 4 en maturité des données, économie de l'erreur, supervision, adéquation réglementaire, délai de valeur et capacité d'évaluation, et 3 en intégration, obtient 86. C'est un bon candidat pour un pilote encadré, et il vaut la peine de remarquer combien de cette note provient d'éléments qui n'ont rien à voir avec le modèle.

Là où ce schéma a tenu

Les résultats publiés se répartissent en deux catégories qu'il ne faut pas mélanger : la recherche indépendante, et les chiffres qu'une entreprise publie sur elle-même.

Microsoft décrit chez Concentrix un traitement documentaire portant sur environ 100 000 factures par mois dans plus de 300 mises en page, avec une précision d'extraction supérieure à 96% atteignant 99% en janvier 2026. Morgan Stanley indique que son assistant d'IA interne est utilisé par 98% des équipes de conseillers financiers, et que son système Debrief produit des comptes rendus et des actions à partir de rendez-vous clients autorisés. Siemens rapporte que les pilotes de son Industrial Copilot pour la maintenance ont réduit le temps de maintenance réactive de 25% en moyenne. DBS a déclaré dans son rapport annuel 2025 plus de 2 000 modèles d'IA et d'apprentissage automatique sur plus de 430 cas d'usage, en attribuant environ 1 milliard de SGD de valeur économique annuelle à l'analytique et à l'IA.

Ces quatre chiffres sont communiqués par les entreprises elles-mêmes. Aucun n'est une estimation contrôlée, et aucun n'est une prévision pour une autre organisation. Ce qui se transfère, c'est l'architecture plutôt que le pourcentage : l'IA absorbe la variabilité, la logique déterministe contrôle le processus métier, et une personne nommée reste responsable des étapes lourdes de conséquences.

Le développement logiciel montre pourquoi les chiffres empruntés sont dangereux. L'essai randomisé de METR a constaté que les outils d'IA du début 2025 rendaient des développeurs open source expérimentés 19% plus lents dans l'environnement testé. En février 2026, METR a indiqué que les outils plus récents apportaient probablement une accélération supérieure à ceux testés initialement, tout en expliquant que des effets de sélection dans la nouvelle expérience rendaient l'ampleur de cette amélioration impossible à estimer de façon fiable. Deux résultats crédibles, à un an d'écart, pointant dans des directions différentes. Mesurez plutôt vos propres développeurs, vos dépôts et votre mélange réel de tâches.

Les problèmes à ne pas confier à l'IA

Cette décision mérite la même rigueur que la recherche de candidats, et c'est là qu'une évaluation gagne l'essentiel de son prix.

Les problèmes à réponse déterministe. N'utilisez pas un modèle de langage pour calculer un impôt, appliquer des droits d'accès, valider des identifiants, calculer des intérêts ou exécuter une logique métier fixe. Utilisez du code. L'IA est précieuse justement là où la logique déterministe cesse d'être praticable.

Le travail à faible volume et faible valeur. Une tâche qui survient quelques fois par an et prend quinze minutes ne justifie pas un système intégré, aussi bonne que soit l'architecture.

Les processus cassés. Validations inutiles, doubles saisies qui devraient disparaître, responsabilités floues, formulaires obsolètes et données de référence défaillantes empirent une fois automatisés, parce que l'automatisation les rend permanents.

Les problèmes sans résultat mesurable. « Devenir AI-first » n'est pas un résultat. « Déployer des agents » et « améliorer l'innovation » non plus. Sans variable opérationnelle ou économique, le projet ne peut pas démontrer qu'il a fonctionné, ce qui signifie généralement qu'il ne sera pas arrêté non plus.

Les tâches dont les erreurs sont coûteuses et invérifiables. L'IA peut encore aider à la préparation et à la recherche dans des contextes à fortes conséquences. L'automatisation complète est difficile à défendre quand les décisions sont irréversibles, quand les défaillances peuvent nuire à des personnes, quand les éléments ne peuvent pas être reconstitués, quand le modèle ne sait pas de façon fiable qu'il se trompe, ou quand aucun relecteur compétent n'existe.

Les problèmes sans données appropriées. Un modèle ne répare pas une réalité métier absente. Documentation périmée, résultats jamais enregistrés, étiquettes peu fiables et droits d'accès inconnus sont des prérequis, pas des détails de mise en œuvre.

Les tâches dont la vérification prend autant de temps que le travail. La supervision humaine ne crée de la valeur que si la relecture coûte moins que le travail sans assistance. Si quelqu'un doit reconstruire chaque réponse pour savoir si elle est juste, le travail a été déplacé, pas supprimé.

L'IA pour l'IA. Gartner indiquait en janvier 2026 qu'au moins 50% des projets d'IA générative avaient été abandonnés après la preuve de concept à la fin de 2025, en citant la mauvaise qualité des données, la faiblesse des contrôles de risque, la hausse des coûts et l'absence de valeur métier claire. La technologie peut fonctionner alors que le projet échoue quand même.

La conformité appartient au cadrage

Pour les entreprises suisses et européennes, la qualification juridique fait partie de l'évaluation d'une opportunité. La découvrir tard est la façon dont un prototype fonctionnel devient inutilisable.

La Suisse n'a pas encore de loi générale sur l'IA. Le Conseil fédéral a chargé l'administration fédérale de préparer une législation mettant en œuvre la Convention du Conseil de l'Europe sur l'IA, un projet de consultation étant attendu d'ici fin 2026 (Chancellerie fédérale). Cela ne signifie pas que l'IA n'est pas encadrée. La loi révisée sur la protection des données s'applique depuis le 1er septembre 2023, et le PFPDT précise que la LPD s'applique au traitement de données personnelles assisté par IA, en insistant sur la transparence et les décisions individuelles automatisées. Lorsqu'une décision individuelle automatisée relève de l'article 21 LPD, le responsable du traitement doit informer la personne concernée et lui permettre de faire valoir son point de vue et de demander un réexamen humain, sous réserve des exceptions légales (PFPDT).

Dans l'Union, le règlement sur l'IA est devenu applicable de manière générale le 2 août 2026, et le calendrier a ensuite changé. L'AI Omnibus est entré en vigueur le 27 juillet 2026 et a repoussé les dates d'application des principales obligations à haut risque au 2 décembre 2027 pour les systèmes de l'annexe III et au 2 août 2028 pour l'IA à haut risque intégrée aux produits réglementés de l'annexe I (règlement (UE) 2026/1744, ainsi que les pages de mise en œuvre de la Commission européenne). Certaines règles de transparence s'appliquent déjà depuis août 2026. Les organisations suisses devraient lire attentivement l'article 2 sur le champ d'application territorial, car il couvre certains fournisseurs et déployeurs de pays tiers lorsque le résultat est utilisé dans l'Union. Là où le RGPD s'applique, l'article 22 confère en outre le droit de ne pas faire l'objet de certaines décisions fondées exclusivement sur un traitement automatisé. Ceci n'est pas un conseil juridique, et la conséquence pratique est seulement que la qualification est peu coûteuse au cadrage et coûteuse après la construction.

Acheter le modèle, construire le processus

Dès qu'un cas d'usage survit à la priorisation, décidez quelle part vous avez réellement besoin de construire. Acheter quand le problème est banalisé, qu'un logiciel mature le traite déjà, que l'intégration est légère, la différenciation faible et le modèle de sécurité et de traitement des données du fournisseur acceptable. Construire ou adapter quand le processus ou les données propres sont au centre, qu'une intégration profonde à l'ERP ou au CRM est nécessaire, que les droits d'accès sont particuliers, que les exigences d'auditabilité sont inhabituelles, ou que le logiciel disponible ne correspond pas au processus.

Pour la plupart des entreprises, ce n'est pas binaire. L'architecture courante consiste à acheter le modèle ou la plateforme et à construire autour le flux, l'intégration, les droits, l'évaluation et la gouvernance. Posséder un modèle de fondation est rarement le facteur de différenciation. Posséder le processus autour l'est souvent.

Le déploiement suit la même logique.

Le raccourci à éviter est que le cloud serait peu sûr et l'auto-hébergement sûr. Un système de recherche auto-hébergé dont les droits sur les documents sont mal réglés divulguera parfaitement bien des informations confidentielles. Ce qui compte, c'est la classification des données, la localisation, la conservation, les relations de sous-traitance, le chiffrement, l'identité et les droits, le volume, la latence, la résilience, le coût, la surveillance, le cycle de vie des modèles, la gestion des incidents et la question de savoir qui est responsable à trois heures du matin. L'auto-hébergement apporte le contrôle et transfère la responsabilité dans le même mouvement.

L'évaluation ne s'arrête pas au lancement

Une démonstration convaincante n'est pas une preuve. Le cadre de gestion des risques de l'IA du NIST recommande de tester les systèmes d'IA avant leur déploiement et régulièrement pendant leur exploitation, et traite la surveillance en production comme une partie de la gestion des risques, car le comportement change avec les données et les conditions.

Deux niveaux sont nécessaires. La qualité du système couvre la précision, la justesse et le rappel, l'erreur d'extraction, le taux de réponses non étayées, la pertinence de la recherche, le succès des appels d'outils, les taux d'escalade et de correction, la latence, le coût par tâche réussie et la reprise après défaillance. La qualité métier mesure le résultat pour lequel le projet existait : débit, coût, temps de cycle, arriéré, respect des engagements, coût des erreurs, chiffre d'affaires, conversion, indisponibilité ou satisfaction. Le cycle d'exploitation est : évaluer, déployer, surveiller, recueillir les retours, tester les régressions, mettre à jour. Un système d'IA est un logiciel en exploitation, pas un projet d'innovation achevé.

Par où commencer

Vous n'avez pas besoin de six mois de travail stratégique pour trouver le premier candidat. Repérez les processus coûteux ou contraints. Notez la situation de départ : volume, temps, qualité, coût. Cartographiez le flux réel, exceptions et contournements compris. Supprimez ce qui ne devrait pas exister. Comparez ensuite les classes de solutions dans cet ordre : refonte du processus, logiciel et API, automatisation de flux, assistance par IA, et seulement ensuite automatisation par IA. Appliquez les quatre conditions, notez ce qui subsiste, et construisez le plus petit flux complet avec des données représentatives et de vrais points d'intégration, car un agent conversationnel déconnecté des systèmes ne prouve presque rien.

Comparez ensuite à la situation de départ, et soyez prêt à arrêter. Un pilote qui montre que l'IA ne devrait pas être déployée a produit un résultat utile et économisé le budget de production.

Chez Alpine Edge, nous traitons la recherche d'opportunités comme un travail d'analyse métier et d'ingénierie avant d'en faire un exercice d'IA. Le résultat que nous visons n'est pas une longue liste d'applications possibles. C'est une liste plus courte de problèmes qui valent la peine d'être résolus, les preuves de l'adéquation de l'IA, une architecture qui convient à l'organisation, et des raisons explicites d'écarter le reste. Si vous en êtes là, une évaluation technique ciblée est généralement un meilleur premier pas que l'engagement dans un programme, et nous accompagnons les cas qui subsistent du cadrage à une exploitation fiable, en passant par l'architecture et l'intégration.

D'où viennent ces chiffres

• Eurostat, usage de l'IA dans les entreprises de l'UE. Chiffres d'adoption 2025.
• McKinsey, The State of AI 2026. Effet sur le résultat d'exploitation, entreprises très performantes, contrainte de coûts.
• Brynjolfsson, Li et Raymond, Generative AI at Work. Quarterly Journal of Economics ; 5 172 agents du service client.
• Dell'Acqua et al., Navigating the Jagged Technological Frontier. Organization Science ; 758 consultants.
• Gartner, le manque de données prêtes pour l'IA met les projets en risque. Enquête auprès de 1 203 responsables et prévision associée.
• Gartner, pourquoi la moitié des projets d'IA générative échouent. Analyse de janvier 2026.
• METR, étude de productivité début 2025. Essai randomisé avec des développeurs expérimentés.
• METR, mise à jour de février 2026. Pourquoi le résultat le plus récent ne peut pas être chiffré de façon fiable.
• Microsoft, traitement documentaire chez Concentrix. Volume et précision communiqués par l'entreprise.
• Morgan Stanley, AI Assistant et Debrief. Adoption communiquée par l'entreprise.
• Siemens, Industrial Copilot pour la maintenance. Résultat de pilote communiqué par le fournisseur.
• DBS, rapport annuel 2025. Portefeuille et valeur communiqués par l'entreprise.
• Commission européenne, cadre réglementaire pour l'IA. Dates d'application du règlement sur l'IA.
• EUR-Lex, règlement (UE) 2026/1744. L'AI Omnibus et les nouvelles échéances à haut risque.
• EUR-Lex, règlement sur l'IA. Texte officiel, dont l'article 2 sur le champ d'application territorial.
• EUR-Lex, RGPD. Article 22 sur les décisions individuelles automatisées.
• PFPDT, IA et protection des données. Applicabilité de la LPD aux traitements assistés par IA.
• PFPDT, devoir d'information. Article 21 LPD et décisions individuelles automatisées.
• Chancellerie fédérale, réglementation de l'IA. État de la législation suisse et consultation prévue.
• NIST, AI Risk Management Framework. Tests avant déploiement et surveillance en production.