Approche
Ce qui crée de la valeur dans un mandat IA
Il y a un malentendu répandu sur le rôle d’un consultant en IA. La valeur ne vient pas du fait d’arriver, de construire un objet technique, puis de partir. Elle vient de quatre choses.
Le diagnostic avant la solution
La plupart des demandes arrivent avec une solution déjà en tête, un agent conversationnel, une automatisation précise. Le travail consiste d’abord à vérifier que cette solution répond au vrai problème. Souvent il y a un problème plus large derrière, ou une solution plus simple qui convient mieux.
L’architecture qui tient dans le temps
Les décisions prises au début d’un projet déterminent s’il sera maintenable dans deux ans. Un système qui coûte trop cher à opérer ou qui casse à chaque mise à jour de modèle, cela commence par des choix initiaux qu’on aurait pu faire autrement.
La formation implicite
Un bon mandat laisse l’organisation capable de comprendre ce qui a été construit, de l’évaluer, et d’intervenir si nécessaire. La dépendance perpétuelle au consultant n’est dans l’intérêt de personne.
Le plan de maintenance
Qui surveille le système. Comment on sait qu’il se dégrade. Quand on intervient. Ces questions se répondent avant le déploiement, pas après le premier incident.
Diagnostic
Les cinq questions posées avant tout mandat
Ces questions ne servent pas à filtrer. Elles servent à éviter que les deux parties perdent du temps et de l’argent sur un projet mal posé. Si une organisation peut y répondre clairement, on peut commencer. Si elle ne peut pas encore, y répondre ensemble est le travail le plus utile qu’on puisse faire.
- 01
Quel problème concret voulez-vous résoudre ?
Pas « utiliser l’IA », pas « devenir une organisation IA-first », mais un problème spécifique avec un coût mesurable aujourd’hui. Par exemple, un nombre d’heures par mois passées à saisir des données de facturation.
- 02
Comment savez-vous que ce problème vaut le coût de le résoudre ?
Le coût manuel actuel doit dépasser le coût total de la solution, c’est-à-dire la construction, la maintenance et les risques. Si ce calcul n’a pas été fait, on le fait ensemble avant de commencer.
- 03
Que se passe-t-il si le système fait une erreur ?
La réponse détermine l’architecture. Un système qui peut se permettre un pour cent d’erreur est très différent d’un système où un pour cent d’erreur coûte plusieurs milliers de dollars par incident.
- 04
Qui va maintenir ce système dans six mois ?
Si la réponse est « on verra », l’automatisation crée une dépendance qui peut se retourner contre l’organisation. Le plan de maintenance doit exister avant le plan de déploiement.
- 05
Quelle est votre tolérance à un déploiement progressif ?
Les meilleurs déploiements commencent sur un sous-ensemble de cas, avec des humains qui surveillent. Les pires commencent à pleine échelle et corrigent dans l’urgence.
Un projet qui stagne, ou une décision d’architecture à prendre ?
Le premier appel dure 30 minutes et sert à cadrer le problème. Il est gratuit et sans engagement. Si un mandat n’a pas de sens, vous repartez quand même avec une lecture claire de votre situation.
Réserver un appel de 30 minutes