Commencer par une tâche, pas par un outil
La question « quel outil choisir ? » arrive trop tôt. La bonne première question : quelle tâche consomme du temps ou génère des erreurs de façon répétée, et que changerait le fait de la faire mieux ?
Dans une PME, les candidates typiques : trier et qualifier les demandes entrantes, saisir les données de factures fournisseurs, rédiger les premières versions de réponses au service client, retrouver une procédure interne, préparer un compte rendu à partir de notes. Toutes sont fréquentes, délimitées, et leur résultat se juge facilement.
À l’inverse, les tâches qui engagent une responsabilité forte, reposent sur un jugement rare ou touchent à des données très sensibles ne sont pas de bonnes premières candidates.
Quatre critères pour choisir le premier cas d’usage
La fréquence. Une tâche réalisée plusieurs fois par jour par plusieurs personnes justifie un effort d’automatisation ; une tâche mensuelle rarement.
La description. Si personne ne peut expliquer comment la tâche est faite aujourd’hui, étape par étape, avec ses exceptions, elle n’est pas prête. Décrire le processus actuel est d’ailleurs souvent la partie la plus utile du projet, IA ou non.
La vérifiabilité. Vous devez pouvoir dire si le résultat est bon ou mauvais. Une facture dont les montants sont extraits se vérifie en quelques secondes ; une « meilleure stratégie commerciale » ne se vérifie pas.
Le coût de l’erreur. Si, quand le système se trompe, quelqu’un corrige en relisant, le cas est bon. Si un client reçoit une information fausse, il faudra un contrôle humain systématique.
Les données : ce qu’il faut vérifier avant de se lancer
Une IA branchée sur de mauvaises données produit de mauvais résultats avec assurance. Trois vérifications s’imposent.
Les données existent-elles sous une forme exploitable ? Des procédures dans la tête des anciens, des contrats scannés de travers ou des tableurs aux colonnes changeantes demandent d’abord un travail de mise en forme.
Sont-elles à jour ? Un assistant qui répond à partir d’une version obsolète du catalogue ou du règlement intérieur fait plus de mal qu’un moteur de recherche.
Qui a le droit d’y accéder ? Si l’assistant interne peut lire les fiches de paie parce qu’elles sont stockées à côté des procédures, vous avez un problème avant la première question. Les droits d’accès se pensent avant le branchement.
Décider ce que le système peut faire seul
Le point le plus souvent négligé est le niveau d’autonomie. Trois positions sont possibles : le système propose et un humain valide tout ; le système agit seul dans un périmètre délimité et signale les cas douteux ; le système agit seul et fait l’objet de contrôles a posteriori.
Il est raisonnable de commencer à la première position, puis de déplacer le curseur à mesure que la confiance se construit sur des résultats observés. Ce qui ne doit jamais être laissé au hasard, c’est la règle de repli : quand le système hésite ou rencontre un cas imprévu, qui est prévenu, et comment ?
Cette règle doit être écrite, connue des équipes et testée : un système qui échoue silencieusement est plus dangereux qu’un système qui échoue bruyamment.
Dimensionner un pilote dont on apprend quelque chose
Un bon pilote est assez petit pour être livré rapidement et assez réel pour produire un enseignement. Quelques repères :
- un seul cas d’usage, une seule équipe, un périmètre de données clairement borné ;
- un jeu de cas de test constitué avant le démarrage, avec les résultats attendus, pour mesurer la qualité plutôt que la juger à l’impression ;
- des indicateurs simples définis à l’avance : temps passé, taux de corrections, nombre de cas renvoyés à un humain ;
- une date de bilan fixée dès le départ, où l’on décide d’étendre, de corriger ou d’arrêter.
Un pilote qui ne peut pas être arrêté n’est pas un pilote, c’est un déploiement déguisé.
Impliquez les personnes qui font la tâche aujourd’hui : elles connaissent les exceptions non documentées et seront les premières à contourner un outil qui ne leur simplifie rien.
Acheter ou construire
De nombreux outils du marché intègrent des fonctions d’IA ; pour des cas comme le résumé de réunions ou l’aide à la rédaction, une solution existante bien paramétrée suffit. Le sur mesure se justifie quand le cas d’usage dépend de vos données propres, de vos règles métier ou d’une intégration que rien ne couvre.
Le critère n’est pas la sophistication, mais la place de vos données et de vos processus dans la valeur produite.
En résumé
Commencez par une tâche fréquente, bien décrite et vérifiable. Vérifiez que les données nécessaires existent, sont à jour et correctement protégées. Écrivez ce que le système a le droit de faire seul et ce qui se passe quand il hésite. Menez un pilote borné, mesuré, avec une date de bilan.
Pour structurer cette démarche, du choix des cas d’usage à la gouvernance des données, découvrez notre prestation d’intégration de l’IA en entreprise.