Par où commencer avec l’IA ? Choisir un premier processus utile et maîtrisable

Une mauvaise sélection commence souvent par une démonstration : l’équipe découvre une fonction impressionnante, puis cherche où l’installer.

La démarche inverse est plus robuste. Commencez par une situation dont le coût est déjà visible :

• un délai récurrent qui bloque une décision ou un client ;
• une tâche répétée par plusieurs personnes ;
• une information dispersée qu’il faut reconstruire à chaque dossier ;
• un contrôle manuel qui mobilise un expert sur des cas simples ;
• une production standardisée dont les exceptions sont connues.

La question utile n’est pas « que peut faire l’IA ? », mais « quel résultat devons-nous produire plus vite, plus régulièrement ou avec moins d’effort, sans dégrader la responsabilité de l’entreprise ? ».

Cette formulation évite les faux cas d’usage. Résumer un document n’est pas encore un processus. Préparer une note de crédit, répondre à un appel d’offres ou contrôler un pack de reporting en sont, car il existe un déclencheur, des entrées, des étapes, un livrable et une personne responsable.

Avant d’évaluer l’IA, décrivez le fonctionnement réel. Une fiche suffit si elle répond à huit questions :

1. Quel événement déclenche le travail ?
2. Quelles données et quels documents sont nécessaires ?
3. Qui réalise chaque étape ?
4. Quel résultat doit être produit ?
5. Qui le valide et selon quels critères ?
6. Combien de fois le processus se répète-t-il ?
7. Où se trouvent les erreurs, retards ou reprises les plus fréquents ?
8. Que se passe-t-il si le résultat est faux ou arrive trop tard ?

Ajoutez une mesure de départ que vous pourrez comparer après le test : temps de traitement, délai total, nombre de reprises, volume d’exceptions ou taux de dossiers acceptés sans correction. Il n’est pas nécessaire de disposer d’un tableau de bord parfait. Il faut seulement une référence assez fiable pour empêcher le projet de se déclarer lui-même réussi.

Cette étape révèle souvent que le problème n’est pas le modèle. Les données peuvent être inaccessibles, les consignes contradictoires ou la validation inexistante. Automatiser un processus mal défini accélère surtout ses incohérences.

Certains sujets peuvent être importants sans être de bons points de départ.

Écartez d’abord les processus pour lesquels aucune personne compétente ne peut relire le résultat. Une IA ne doit pas devenir le seul juge de sa propre production.

Écartez aussi les cas dont les données ne sont ni accessibles ni autorisées. La CNIL rappelle notamment qu’une entreprise doit identifier les données personnelles ou sensibles et éviter de les introduire dans un outil sans protection adaptée. Le projet doit préciser ce qui peut être transmis, anonymisé, conservé et journalisé.

Traitez séparément les usages qui affectent directement une personne. L’annexe III du règlement européen sur l’intelligence artificielle classe notamment certains systèmes utilisés pour le recrutement, la sélection ou l’évaluation des travailleurs parmi les usages à haut risque. Un premier pilote n’est pas le bon endroit pour découvrir tardivement des obligations de conformité.

Enfin, évitez comme premier choix un processus qui nécessite simultanément plusieurs intégrations, une refonte des données, un changement d’organisation et une décision juridique. Le potentiel peut être réel, mais vous ne saurez pas quelle cause explique le résultat du test.

Un bon premier processus possède au contraire des frontières claires, un volume régulier, un responsable disponible, des données identifiables et un mode manuel qui peut reprendre le relais.

Une direction peut classer ses idées avec une grille simple. Notez chaque critère de 0 à 2. Cette notation est une méthode de décision proposée par Atalas, pas un standard réglementaire.

Ne choisissez pas mécaniquement le score le plus élevé. Utilisez la grille pour rendre l’arbitrage explicite. Un processus très fréquent mais risqué peut attendre. Un sujet légèrement moins rentable mais mieux délimité peut constituer un meilleur premier apprentissage.

Le NIST organise la gestion des risques de l’IA autour de quatre fonctions : gouverner, cartographier, mesurer et gérer. L’idée est directement applicable à ce choix : comprendre le contexte avant de décider, mesurer le comportement du système, puis traiter les risques et réviser la décision dans le temps.

Une idée devient un pilote quand la direction fixe ses limites avant le premier essai.

Le contrat de pilote doit contenir :

• le périmètre exact et les dossiers exclus ;
• le résultat attendu et son format ;
• les données autorisées ;
• l’outil et les connexions utilisées ;
• le propriétaire métier ;
• la personne qui relit ;
• la mesure de départ ;
• les critères d’acceptation ;
• le mode dégradé si l’outil ne répond plus ;
• la date de revue ;
• les conditions d’arrêt.

Le critère d’arrêt est essentiel. Par exemple : arrêter si la relecture prend autant de temps que la production actuelle, si les erreurs graves ne peuvent pas être détectées de manière fiable ou si l’accès aux données exige une transformation disproportionnée.

Sans cette règle, un pilote peut survivre parce que l’équipe a déjà investi du temps, non parce qu’il crée de la valeur.

Une démonstration réussie ne prouve rien sur le fonctionnement quotidien. Testez le processus de bout en bout sur plusieurs cycles réels, avec des dossiers ordinaires et des exceptions connues.

À chaque cycle, consignez :

• le temps de préparation ;
• le temps de calcul ou de génération ;
• le temps de contrôle humain ;
• les corrections apportées ;
• les erreurs non détectées par l’outil ;
• les cas refusés ou renvoyés au mode manuel ;
• les incidents de données ou d’accès.

Comparez ensuite le résultat à la mesure de départ. Le temps « gagné » n’existe que si la capacité libérée est réellement réaffectée, si un délai diminue ou si une dépense est évitée. Notre analyse sur le ROI de l’IA détaille cette différence.

Le contrôle doit porter sur le système complet, pas seulement sur la qualité du texte produit. Un bon modèle branché sur de mauvaises données, sans droits d’accès ni procédure de reprise, reste un mauvais processus d’entreprise.

La revue finale doit aboutir à une décision, pas à une nouvelle phase indéfinie.

Étendez le pilote si le résultat atteint le niveau attendu, si le temps de contrôle reste raisonnable, si les exceptions sont identifiées et si le mode dégradé fonctionne.

Corrigez-le si la valeur apparaît mais qu’un problème précis bloque le passage à l’échelle : qualité des données, consigne métier, intégration ou formation.

Arrêtez-le si le risque reste supérieur au gain, si le processus ne peut pas être mesuré, si la relecture absorbe l’économie ou si l’entreprise devient dépendante d’éléments qu’elle ne peut pas récupérer.

Arrêter un mauvais pilote est une réussite de gouvernance. Cela évite de transformer une expérimentation séduisante en dette opérationnelle.

Prenons une PME de services B2B dont les propositions commerciales sont relues par la direction.

Le déclencheur est une demande qualifiée. Les entrées sont le compte rendu commercial, le catalogue d’offres, les règles de marge et les références autorisées. Le résultat attendu est un projet de proposition, jamais un envoi automatique.

L’IA peut assembler le premier document, vérifier la présence des rubriques obligatoires et signaler une incohérence avec les règles internes. Le commercial reste responsable du besoin client ; la direction valide le prix, les engagements et les exceptions.

Le pilote peut comparer le délai de préparation, le nombre de corrections et le temps de validation sur plusieurs propositions. Il doit s’arrêter si l’outil invente des références, transforme une hypothèse en engagement ou oblige le valideur à reprendre chaque document intégralement.

Cet exemple n’est pas une promesse de gain. Il montre comment transformer une idée générale en décision testable.

À la fin du cadrage, la direction doit disposer de cinq éléments :

1. un processus prioritaire décrit de bout en bout ;
2. une mesure de départ ;
3. un responsable métier et un valideur ;
4. un pilote limité avec des critères d’acceptation et d’arrêt ;
5. une date de décision pour étendre, corriger ou abandonner.

Cette discipline permet de passer d’une liste d’idées à un portefeuille pilotable. Elle complète notre méthode sur le passage des projets IA en production et le traitement du shadow AI.

Atalas accompagne les dirigeants pour sélectionner ces processus, concevoir les contrôles et construire les outils nécessaires dans son Studio IA.

Sources datées

• Insee, « Les technologies de l’information et de la communication dans les entreprises en 2025 », Insee Première n° 2120, publié le 21 juillet 2026 : https://www.insee.fr/fr/statistiques/9025878
• Union européenne, règlement (UE) 2024/1689 sur l’intelligence artificielle, version consolidée au 27 juillet 2026, notamment article 4 et annexe III : https://eur-lex.europa.eu/eli/reg/2024/1689/oj?locale=fr
• NIST, AI Risk Management Framework 1.0, publié le 26 janvier 2023, et AI RMF Core, consultés le 28 octobre 2026 : https://www.nist.gov/itl/ai-risk-management-framework
• CNIL, « Quelles précautions prendre dans le cadre du développement ou de l’utilisation de systèmes d’intelligence artificielle ? », fiche TPE-PME publiée en mars 2025, consultée le 28 octobre 2026 : https://www.cnil.fr/sites/cnil/files/2025-03/tpe_pme_ficheia_4_les_precautions_0.pdf
• ClaudIn, blog consulté le 28 octobre 2026 pour la veille éditoriale sur les questions pratiques des dirigeants : https://www.claudin.tech/blog