Un consultant IA détermine où l’IA changerait l’économie du travail d’une organisation, construit le dossier, repense le workflow autour d’elle, choisit et gouverne la solution, et reste jusqu’à ce que la valeur apparaisse dans les chiffres du client. Le métier consiste surtout en diagnostic, priorisation et refonte. Construire la technologie n’en est qu’une petite part, généralement déléguée.
Le rôle en un paragraphe
Le client n’achète pas de l’IA. Il achète un changement dans le fonctionnement d’une partie de son activité, avec un chiffre associé, et quelqu’un de responsable pour y parvenir.
Presque toutes les organisations utilisent aujourd’hui l’IA quelque part : l’enquête McKinsey 2025 situe l’adoption à 88 %. Bien moins ont changé quoi que ce soit de significatif. Seulement environ une sur cinq déclare avoir fondamentalement repensé un workflow grâce à elle, et environ six pour cent constatent un impact EBIT de cinq pour cent ou plus au niveau de l’entreprise. L’écart entre utiliser l’IA et en tirer de la valeur est là où travaille le consultant. Le métier consiste à trouver les endroits précis d’une organisation où l’IA change l’économie du travail, à construire le dossier, à repenser le travail pour que la technologie puisse produire, et à porter l’initiative jusqu’au point où le résultat est mesurable. Tout ce qui suit est une étape de cette séquence.
Le cycle de mission, étape par étape
Une mission complète comporte treize étapes. Les missions courtes couvrent les six premières et s’arrêtent à une liste priorisée et un dossier métier ; les plus longues mènent une ou plusieurs initiatives jusqu’à la valeur mesurée. L’ordre compte. La plupart des projets IA en échec ont sauté les étapes deux à cinq et sont passés directement d’une idée à une construction.
Séquence issue de l’AI Transformation Framework de World AI University. Les cabinets nomment et regroupent les étapes différemment ; le fond est largement partagé dans la pratique sérieuse.
Ce que le client reçoit réellement
Chaque étape produit quelque chose que le client conserve. Ensemble, ils forment la piste écrite qui permet à un dirigeant de défendre la décision, à une équipe finance de suivre le retour, et à une équipe d’ingénierie de construire la bonne chose.
| Livrable | Ce qu’il contient | Qui l’utilise |
|---|---|---|
| Diagnostic du workflow | Cartographies de l’existant avec volumes, temps de cycle, coûts et fuites de valeur quantifiées | Sponsor, responsables de processus |
| Portefeuille d’opportunités | Longue liste d’opportunités IA, notées et classées, avec la justification de ce qui a été mis de côté | Sponsor, CAIO, comité de pilotage |
| Évaluation de la préparation | Préparation données, technologie, organisation, gouvernance et finance pour les opportunités retenues, avec écarts et remèdes | DSI, CDO, responsable de programme |
| Conception du workflow cible | Processus cible, rôles, points de supervision humaine, gestion des exceptions | Responsables de processus, responsable du changement |
| Dossier métier | Référence, moteurs de valeur, coûts, risques, sensibilité, plan de mesure | CFO, comité d’investissement |
| Stratégie de solution | Recommandation construire / acheter / hybride, évaluation des fournisseurs, dépendances d’intégration et de données | DSI, CTO, achats |
| Conception de la gouvernance | Classification des risques, contrôles, surveillance, escalade, cartographie réglementaire | Risque, juridique, conformité |
| Plan de mise en œuvre | Conception du pilote, critères de succès, plan de changement, séquence de déploiement, jalons de décision | Responsable de programme, PMO |
| Rapport de valeur | Résultat mesuré par rapport à la référence ; recommandation de passage à l’échelle, d’ajustement ou d’arrêt | Sponsor, CFO, conseil |
À quoi ressemble le travail par secteur
La méthode est la même partout ; les workflows et les fuites de valeur, non. Les exemples ci-dessous sont des illustrations génériques du type d’opportunité que le cycle fait généralement émerger, pas des récits de missions précises.
Ce que les consultants IA ne doivent pas faire
L’essentiel des dégâts commis au nom du conseil en IA vient de choses qui ne relèvent pas du conseil. Une courte liste de ce qu’il faut refuser.
- Partir d’une technologie. « Il faut faire quelque chose avec les agents » n’est pas un brief. Si la mission ne commence pas par l’activité et le workflow, le résultat sera une solution en quête de problème.
- Animer un brainstorming et l’appeler stratégie. Un mur de post-it de cas d’usage sans fuite quantifiée derrière produit un portefeuille que personne ne peut prioriser.
- Greffer l’IA sur le processus existant. Ajouter un modèle à une étape sans repenser le workflow autour capte une fraction de la valeur et c’est le schéma le plus associé aux pilotes qui ne passent jamais à l’échelle.
- Vendre la construction. Le consultant qui est aussi développeur a intérêt à recommander de construire. Séparez le rôle de conseil de la livraison, ou soyez transparent sur le fait qu’il ne l’est pas.
- Traiter la gouvernance comme une annexe de conformité. Classification des risques, supervision et surveillance façonnent ce que le workflow peut être. Ils relèvent de l’étape dix, pas d’une diapositive à la fin.
- Partir à la mise en production. Un système déployé n’est pas un résultat. Si personne ne mesure la valeur par rapport à la référence, la mission n’est pas terminée.
- Surestimer la technologie. Les modèles actuels sont extraordinaires sur certaines choses et peu fiables sur d’autres. Un consultant incapable de dire où se situe la frontière pour ce cas d’usage n’est pas encore qualifié pour conseiller.
Les compétences qu’exige le travail
En relisant le cycle, les compétences en découlent directement : analyse métier et cartographie des workflows pour les étapes un à trois ; identification et priorisation des opportunités pour quatre et cinq ; stratégie de solution et gouvernance pour neuf et dix ; construction du dossier métier pour huit ; conduite du changement et communication client tout au long ; et assez de maîtrise technique pour savoir ce qui est faisable et poser les bonnes questions aux ingénieurs. Aucune n’est une compétence de code. Pour le détail de chacune, comment elle se manifeste en mission et comment la développer, voir Comment devenir consultant IA en 2026.
Le produit du consultant est une partie de l’entreprise repensée avec un résultat mesuré. La technologie n’en est qu’un intrant.
Le cycle ci-dessus est la structure que World AI University enseigne dans son programme Certified AI Consultant, dans lequel les participants appliquent chaque étape à une véritable initiative client sur sept semaines et font revoir l’initiative obtenue par un comité du World AI Council avant la certification.
Sept semaines ; le cycle complet appliqué à une véritable initiative client ; revu par le World AI Council.
Découvrir le programme Certified AI ConsultantQuestions fréquentes
Un consultant IA construit-il l’IA ?
Généralement non. Le consultant décide ce qui doit être construit, dans quel workflow, sous quels contrôles, et prouve que cela a fonctionné. Des ingénieurs ou un fournisseur le construisent. Les consultants IA techniques sont l’exception et conseillent directement sur l’architecture et l’ingénierie.
Quelle est la durée d’une mission typique ?
Un diagnostic couvrant les étapes un à six prend généralement de deux à six semaines. Mener une initiative de la refonte, du dossier métier, de la gouvernance et de la mise en œuvre jusqu’à la valeur mesurée prend généralement de trois à neuf mois, selon l’organisation et la solution.
Quelle différence entre un consultant IA et un Chief AI Officer ?
La même capacité, exercée depuis des positions différentes. Le Chief AI Officer porte le portefeuille IA depuis l’intérieur de l’organisation, avec une responsabilité permanente. Le consultant apporte la méthode et le regard extérieur à une mission définie. Beaucoup de CAIO ont débuté comme consultants, et inversement.
Qui engage des consultants IA ?
Les PDG, COO et dirigeants fonctionnels qui portent un compte de résultat ou une base de coûts ; les Chief AI Officers qui construisent un portefeuille ; les bureaux de transformation ; et, dans le mid-market, les propriétaires et directeurs généraux. L’acheteur est presque toujours quelqu’un de responsable d’un résultat métier plutôt que de la technologie.
Comment mesure-t-on le succès ?
Par rapport à la référence fixée dans le dossier métier, dans les propres indicateurs opérationnels du client : temps de cycle, coût unitaire, capacité, taux d’erreur, chiffre d’affaires, marge. Une mission réussie produit un chiffre que le CFO accepte.