Qu’est-ce que la qualification du besoin et du processus ?
La qualification du besoin décrit le problème opérationnel à résoudre : le processus concerné, ses entrants et ses sortants, les règles métier qui s’appliquent, les utilisateurs et le résultat attendu. Elle précède le choix d’une technologie, y compris celui de l’intelligence artificielle (IA).
Cette étape teste une hypothèse simple mais rarement vérifiée : l’IA est-elle la réponse la plus fiable ? Un processus régi par des règles stables se traite mieux par de la logique déterministe, plus prévisible, plus économique et plus facile à auditer.
Décrivez le processus concerné, l’irritant constaté et le résultat que vous attendez.
Qualifier votre besoin→Comment se déroule la qualification ?
- 1
Reformuler le problème
Décrire l’irritant tel qu’il est vécu : où le temps se perd, quelle erreur se répète, quelle décision reste bloquée.
- 2
Cartographier le processus
Relever les étapes réelles, les entrants, les sortants, les exceptions et les personnes qui valident chaque passage.
- 3
Éprouver les alternatives
Comparer une évolution du processus, une règle déterministe, une automatisation classique et un usage IA.
- 4
Fixer les critères de succès
Définir ce qui devra être constaté, par qui, sur quelle période, et à partir de quelle situation de départ.
Quand l’IA n’est-elle pas la bonne réponse ?
Écarter l’IA sur un cas d’usage n’est pas un échec de cadrage : c’est souvent le résultat le plus rentable, parce qu’il évite d’engager un budget sur une solution moins fiable que celle déjà disponible.
Lorsqu’un processus repose sur des règles écrites, stables et vérifiables — un calcul de remise, un contrôle de cohérence, un routage de document selon un critère explicite — une implémentation déterministe donne un résultat identique à chaque exécution, auditable et sans coût variable. Confier cette tâche à un modèle introduit une variabilité et un coût d’inférence sans bénéfice, tout en compliquant la justification du résultat en cas de contestation.
D’autres cas relèvent d’un problème de données ou d’organisation. Si l’information nécessaire n’existe pas, arrive trop tard ou circule par des fichiers ressaisis à la main, aucun modèle ne compensera ce manque. Le besoin réel est alors de fiabiliser le flux, ce qui produit souvent un gain immédiat et rend un usage IA envisageable ensuite, sur un socle maîtrisé.
Enfin, certaines tâches sont exclues pour des raisons de responsabilité ou de conformité : décision individuelle concernant une personne, engagement contractuel, élément soumis à un contrôle réglementaire. L’IA peut y préparer un matériau, mais la décision reste humaine et le périmètre doit l’indiquer explicitement. La matrice d’exclusion sert précisément à consigner ces frontières avant que le projet ne les franchisse par facilité.
Quels signes montrent qu’un besoin n’est pas encore qualifié ?
- 01
Le besoin est exprimé par une solution
La demande arrive sous la forme « il nous faut un chatbot » ou « il faut un agent », sans que le problème opérationnel ait été décrit.
- 02
Personne ne sait ce qu’il faudra constater
Aucun critère de réussite n’est formulé dans les termes du métier, ce qui rendra toute évaluation impossible après livraison.
- 03
Les exceptions ne sont pas connues
Le processus est décrit dans son cas nominal alors que l’essentiel du temps passé concerne les situations particulières.
- 04
Le périmètre grossit à chaque réunion
De nouveaux besoins s’ajoutent sans arbitrage, rendant le chiffrage et la faisabilité impossibles à établir sérieusement.
Un cadrage court, mené avec ceux qui font le travail
La qualification se conduit avec les personnes qui exécutent le processus, pas seulement avec leurs responsables. Ce sont elles qui connaissent les exceptions, les contournements installés et les informations manquantes qu’elles vont chercher ailleurs. Sans elles, le cadrage décrit un processus théorique et le projet découvre la réalité en phase de recette.
Nous restons agnostiques à ce stade : aucune technologie, aucun fournisseur, aucune architecture n’est présupposé. Cette neutralité est ce qui permet de recommander une solution sans IA lorsque c’est la bonne réponse, et de défendre un investissement IA avec crédibilité lorsque le besoin le justifie.
Le livrable reste léger et lisible par une direction générale. L’objectif n’est pas de produire un cahier des charges à ce stade, mais de savoir s’il vaut la peine d’engager l’audit de faisabilité et le chiffrage qui suivent.
Quels livrables recevez-vous ?
De quoi décider s’il faut aller plus loin
Le détail dépend du processus étudié et de la disponibilité des personnes qui le connaissent réellement.
