Consultant IA vs AI engineer : conseiller ou construire
La différence tient au livrable, et elle est plus tranchée que celle qui sépare la plupart des paires de ce site. Le consultant rend un document : une analyse, un ordre de priorités, un chiffrage, une recommandation. Sa valeur tient à la qualité du raisonnement, et son travail s’achève quand la décision est prise. L’AI engineer rend un système qui tourne : du code, une recherche documentaire, des garde-fous, un jeu d’évaluation qui dit si le tout fonctionne. Sa valeur tient à ce que la chose marche, et son travail s’achève quand elle est en production. Les deux métiers se rencontrent sur les mêmes projets et se jugent mal l’un l’autre : l’ingénieur trouve que le consultant recommande des choses infaisables, le consultant trouve que l’ingénieur ne voit pas les contraintes de l’organisation. Les deux ont raison, et les projets qui réussissent sont ceux où les deux fonctions se parlent après la phase de cadrage, ce qui est rarement organisé.
Ce que chacun peut promettre
L’ingénieur peut promettre un système qui fonctionne, et il peut le prouver : un jeu d’évaluation constitué de cas réels donne un chiffre que personne ne discute. C’est une promesse vérifiable, ce qui est rare.
Le consultant peut promettre un raisonnement défendable, un ordre de priorités et un chiffrage. C’est une promesse réelle et elle ne se vérifie qu’au bout d’un an, quand on sait si la recommandation a été exécutée et si elle a produit ce qui était annoncé.
Aucun des deux ne peut promettre l’adoption. Elle dépend de la modification d’un indicateur de performance, d’un porteur interne disponible, et d’une décision de direction, c’est-à-dire de choses qu’aucun prestataire ne contrôle. Une promesse de ce type, de l’un ou de l’autre, mérite de la méfiance plutôt que de l’enthousiasme.
Pourquoi le conseil gagne à prototyper
La variable qui décide le plus souvent de la faisabilité d’un projet est l’état réel des données, et elle n’apparaît dans aucun entretien. Un champ supposé renseigné l’est à soixante pour cent, et la logique des quarante pour cent manquants change la conclusion.
Un consultant capable de passer trois jours dans les données produit une recommandation d’une autre qualité qu’un rapport de trois mois fondé sur des conversations. Il ne construit pas, il vérifie, et c’est une distinction que les cabinets ont mis du temps à admettre.
L’inverse vaut également : un ingénieur qui passe une journée à observer le travail se faire conçoit autrement. Ce qui sépare réellement ces deux métiers n’est donc pas la compétence technique mais ce que chacun accepte d’aller regarder.
Où mène chacune des deux voies
Le conseil construit vite un réseau et une intuition des organisations. À cinq ans, un consultant a vu davantage de contextes qu’un ingénieur n’en verra en dix, et cette largeur sert dans tous les postes de direction.
L’ingénierie construit une compétence qui se vérifie. Elle se transporte partout et ne dépend d’aucune relation : un système qui fonctionne reste une preuve, quel que soit l’employeur.
L’asymétrie qui compte porte sur les passages. Un ingénieur qui veut passer au conseil le fait sans difficulté, parce que sa crédibilité technique lui ouvre la porte. Un consultant qui veut passer à l’ingénierie doit combler une profondeur technique qui ne s’acquiert pas en assistant à des réunions, ce qui demande un effort réel et quelques mois.
Pourquoi les deux se jugent mal
Les deux métiers se rencontrent sur les mêmes projets et se critiquent avec régularité. L’ingénieur trouve que le consultant recommande des choses infaisables ; le consultant trouve que l’ingénieur ne voit pas les contraintes de l’organisation. Les deux griefs sont fondés et ils décrivent le même défaut de dispositif.
Dans la plupart des organisations, le consultant n’est plus là quand l’écart entre la recommandation et la réalité se manifeste, et c’est l’équipe technique qui l’absorbe. Elle s’écarte alors du plan pour tenir les délais, sans le documenter, ou respecte un plan qu’elle sait inadapté parce qu’il a été validé plus haut. Les deux issues sont mauvaises.
Le remède est le même que pour la paire architecte et déploiement : garder le consultant disponible, en temps limité mais réel, pendant les premières semaines de construction, avec le mandat explicite de réviser sa propre recommandation. Cela coûte quelques jours et épargne des trimestres, et c’est presque jamais prévu au contrat.
Lire une annonce sans se tromper
Une seule question suffit et elle est posable en entretien : à quoi ressemblera le livrable de la première mission. Un document, ou quelque chose qui tourne.
Les annonces sont généralement honnêtes sur ce point, même quand leur intitulé ne l’est pas. Une offre de consultant qui décrit des intégrations et une chaîne de traitement cherche un ingénieur ; une offre d’ingénieur qui décrit des ateliers et des cartographies cherche un consultant.
La réponse détermine aussi ce qui sera évalué en entretien, et c’est une raison pratique de poser la question tôt plutôt que de préparer les mauvais exercices.
Une dernière précaution vaut pour les deux intitulés. Une annonce qui décrit à la fois du conseil et de la construction décrit souvent un poste réel, celui d’une petite structure où une personne fait les deux, et parfois un poste mal défini que personne n’a tranché en interne. La façon de les distinguer est de demander qui occupait le poste avant, et ce qu’il a produit. Une réponse précise indique un métier ; une réponse embarrassée indique une organisation qui n’a pas encore décidé ce qu’elle cherchait.
