# Le métier de coordinateur de projet IA : rôle et interlocuteurs

> Piloter un projet IA sans être développeur · Leçon 1/10 — SFM Academy (successfor-me.ch).

Cours : https://successfor-me.ch/academy/cours/fiche/IA-18 · Résumé du cours : https://successfor-me.ch/md/cours/IA-18

**À retenir :**

- Coordonner un projet IA, ce n'est pas construire l'outil : c'est faire le pont entre le besoin métier flou et l'équipe technique, en traduisant un souhait en projet livré — vous êtes le maître d'ouvrage, pas le maçon.
- On n'a pas besoin de coder pour piloter : les trois compétences qui décident du succès sont non techniques — cadrer un besoin précis, questionner sans se laisser intimider par le jargon, arbitrer entre coût, délai, qualité et risque.
- Le métier est fait à 80 % d'écoute du terrain, de conversations, d'arbitrages et de documentation courte, 20 % de contact avec la technique — jamais pour coder, toujours pour cadrer et contrôler.
- Vos quatre interlocuteurs veulent des choses différentes : direction (vitesse et retour), métier/utilisateurs (respect de leur travail, pas de remplacement), prestataire (contrat confortable), IT (sécurité des données) — votre valeur est de tenir ces fils à la fois.
- Quatre livrables forment un système : cahier des charges précis, grille d'évaluation des prestataires, plan de pilote avec critères de succès fixés d'avance, tableau de ROI honnête incluant les coûts cachés.
- On ne déploie jamais en grand d'un coup : un pilote de quelques semaines sur de vrais dossiers économise des mois de dégâts et des milliers de francs jetés dans un outil inutile.
- Le meilleur projet IA n'est ni le plus ambitieux ni le plus cher, c'est le mieux cadré : un petit périmètre bien résolu ouvre la porte au suivant, par la preuve plutôt que par la promesse.
- La posture juste est le pont, jamais le camp : partir du problème et non de la solution, protéger le périmètre, exiger le langage clair, et assumer d'être le porteur de la mauvaise nouvelle dite tôt.

**Plan de la leçon :** Traduire un besoin métier en projet : le vrai travail · Pourquoi on n'a pas besoin de coder : cadrer, questionner, arbitrer · Une semaine type, du lundi au vendredi · Vos quatre interlocuteurs — et ce que chacun attend vraiment · Ce que vous produisez réellement : vos quatre livrables · Cas chiffré : la PME de logistique genevoise · Les erreurs de débutant · La posture : le pont, pas le camp

_Leçon en accès libre._

## Traduire un besoin métier en projet : le vrai travail

Un jour, dans une PME romande, quelqu'un dit une phrase de ce genre : « On perd un temps fou à trier les demandes clients à la main, il paraît que l'IA peut faire ça, tu peux t'en occuper ? » Cette personne, c'est vous. Vous n'êtes pas développeur, vous n'avez jamais écrit une ligne de code, et pourtant on vient de vous confier un projet d'intelligence artificielle. Ce cours existe pour vous montrer que c'est non seulement possible, mais que c'est exactement pour ce genre de personne — vous — que le rôle a été inventé.

Commençons par nommer précisément le métier. Coordonner un projet IA, ce n'est pas construire l'outil. C'est faire le pont entre deux mondes qui, seuls, ne se comprennent pas : d'un côté le besoin métier — flou, exprimé en langage humain, « on veut gagner du temps sur le tri des demandes » — et de l'autre l'équipe technique ou le prestataire, qui parle en données, en interfaces et en délais. Votre travail est de transformer un besoin vague en un projet clair, puis de veiller à ce que ce qui sort du côté technique corresponde vraiment à ce dont le métier avait besoin. Vous êtes le traducteur, pas le constructeur.

Cette distinction est vitale, car on confond votre rôle avec trois autres. Le premier est celui du **développeur** ou de l'ingénieur : lui écrit le code, choisit les technologies, fait fonctionner la machine. Ce n'est pas vous, et vous n'avez pas à le devenir. Le deuxième est celui du **prestataire** — l'agence ou le fournisseur qui vend la solution : il connaît son produit, mais il ne connaît ni votre entreprise, ni vos gens, ni vos vraies contraintes, et il repartira une fois payé. Le troisième est celui du **décideur** — la direction qui a l'idée et le budget, mais ni le temps ni la méthode pour transformer une intuition en projet livré. Vous êtes celui qui manque à tous les trois : celui qui reste, qui connaît le terrain, et qui sait mener un projet de bout en bout sans être technicien.

💡 Une image pour tenir tout le cours : vous êtes le **maître d'ouvrage**, pas le maçon. Quand une famille fait construire une maison, elle n'apprend pas à couler du béton. Elle décrit ce qu'elle veut, choisit un entrepreneur, contrôle que les murs sont droits, arbitre entre deux options quand un imprévu surgit, et vérifie à la fin que la maison livrée est bien celle qu'elle avait commandée. Elle n'a jamais tenu une truelle. C'est exactement votre position sur un projet IA : vous commandez, vous cadrez, vous contrôlez, vous arbitrez — vous ne codez pas.

Pourquoi ce rôle existe-t-il, et pourquoi maintenant ? Parce que la plupart des projets IA en PME n'échouent pas pour des raisons techniques. Ils échouent parce que personne n'a clairement défini le problème à résoudre, parce que le prestataire a livré quelque chose de brillant mais d'inutile, ou parce que l'outil, une fois livré, ne correspondait pas au travail réel des gens. Ce sont des échecs de coordination, pas des échecs de technologie. Et une PME de trente personnes ne recrute pas un chef de projet informatique à plein temps pour cela : elle a besoin de quelqu'un du métier, qui comprend l'entreprise, et qui apprend à piloter. Ce quelqu'un, c'est le profil que ce cours forme.

Ce cours prolonge le cursus phare « Devenir spécialiste IA & automatisation » (IA-14). Là où le module 2 de ce cursus vous a montré comment reconnaître les tâches qu'on peut automatiser et à quoi ressemble une bonne solution IA, IA-18 se concentre sur la conduite du projet : comment cadrer le besoin, choisir et piloter un prestataire, mener un pilote, mesurer le retour. C'est la différence entre savoir qu'une maison est possible et savoir la faire construire. Vous savez peut-être déjà repérer une bonne opportunité d'IA ; ici, vous apprenez à en faire un projet livré.

Un dernier mot pour poser le décor. Dans une PME romande, vous n'aurez presque jamais d'équipe dédiée, de budget confortable ni de temps illimité. Vous piloterez ce projet en plus de votre travail habituel, avec un prestataire externe et une direction pressée. C'est précisément dans ce contexte contraint que la coordination fait toute la différence : un projet bien cadré et bien piloté, même modeste, aboutit ; un projet mal cadré, même avec un bon prestataire et un gros budget, se perd. Tout le métier tient dans cet écart entre une bonne idée et un résultat livré. Le franchir, c'est votre travail.

## Pourquoi on n'a pas besoin de coder : cadrer, questionner, arbitrer

L'objection revient toujours au début : « Mais je n'y connais rien en informatique, comment pourrais-je piloter un projet IA ? » Cette objection repose sur une erreur de fond : croire que la compétence centrale d'un projet IA est technique. Elle ne l'est pas. Les trois compétences qui décident du succès sont accessibles à n'importe quel bon professionnel du métier, et aucune ne demande d'écrire du code. Détaillons-les, car elles structurent tout le cours.

**Cadrer.** Cadrer, c'est transformer un besoin flou en une définition précise du problème à résoudre. « On veut de l'IA pour le service client » n'est pas un projet ; c'est un souhait. « On veut réduire de moitié le temps passé à rédiger le premier jet des réponses aux réclamations standard, sans dégrader la qualité perçue par le client » est un projet. La différence entre les deux n'est pas technique : c'est un travail de clarté, de découpage et de bon sens. Un bon cadrage fixe le problème, le périmètre — ce qui est dans le projet et surtout ce qui n'y est pas —, le résultat attendu et la manière dont on saura qu'on a réussi. Neuf projets IA sur dix qui dérapent ont dérapé faute de cadrage, pas faute de technologie. C'est votre première arme, et elle est entièrement non technique.

**Questionner.** Vous ne connaissez pas la technique ? Tant mieux : cela vous oblige à poser des questions, et poser les bonnes questions est une compétence plus rare et plus utile que savoir coder. Face à un prestataire qui affirme « notre IA atteint 95 % de précision », le débutant impressionné hoche la tête ; le bon coordinateur demande : « 95 % de précision sur quel jeu de données ? Que se passe-t-il pour les 5 % restants ? Qui les détecte ? Combien coûte une erreur ? » Vous n'avez pas besoin de comprendre l'algorithme pour poser ces questions ; vous avez besoin de comprendre votre métier et de refuser les réponses vagues. ⚠️ Votre pire ennemi n'est pas votre ignorance technique, c'est l'intimidation par le jargon : le jour où vous acceptez un mot que vous ne comprenez pas sans demander « qu'est-ce que ça veut dire concrètement pour nous ? », vous avez perdu le contrôle du projet.

**Arbitrer.** Un projet est une suite de choix, et presque aucun n'est purement technique. Faut-il une solution parfaite qui coûte CHF 40'000 ou une solution à 80 % qui coûte CHF 8'000 ? Faut-il livrer vite un périmètre réduit ou attendre six mois un outil complet ? Faut-il accepter que l'IA se trompe parfois, et à quel prix ? Ces arbitrages entre coût, délai, qualité et risque sont des décisions de gestion, pas d'ingénierie. Le développeur peut vous dire ce qui est possible ; il ne peut pas décider ce qui est souhaitable pour votre entreprise. Cela, seul quelqu'un qui connaît le métier, les clients et les moyens peut le trancher. C'est vous.

📌 Résumons le renversement, car il libère : la partie technique — comment l'IA fonctionne — est confiée à ceux dont c'est le métier, développeur ou prestataire, et vous n'avez pas à la maîtriser. La partie qui décide du succès — quel problème résoudre, quelles questions poser, quels compromis accepter — est confiée à vous, et elle ne demande aucun code. On n'attend pas de vous que vous compreniez comment le moteur tourne, mais que vous sachiez où l'on veut aller, à quel prix, et si l'on y est arrivé.

Cela ne veut pas dire que vous resterez totalement ignorant. Vous devrez acquérir une **culture générale** de l'IA : savoir grosso modo ce qu'un outil sait bien faire et ce qu'il fait mal, comprendre qu'il peut produire des réponses fausses avec assurance, saisir pourquoi la qualité des données compte. C'est le niveau d'un conducteur qui sait qu'une voiture a besoin d'huile et de pneus corrects sans savoir remonter un moteur. Ce cursus vous donne cette culture. Mais entre « comprendre assez pour piloter » et « savoir construire », il y a un gouffre — et vous n'avez besoin de traverser que le premier.

💡 Le savoir-faire tacite, ici, tient en une phrase : votre ignorance technique, loin d'être un handicap, est souvent un atout de coordinateur. Elle vous force à exiger que tout soit expliqué en langage clair — et un prestataire incapable d'expliquer simplement ce qu'il fait est un prestataire dont il faut se méfier. Le pilote qui « en connaît un peu » se laisse endormir par le jargon ; celui qui assume n'y rien connaître oblige tout le monde à parler la langue du résultat concret. C'est cette langue, et elle seule, qui fait aboutir un projet.

## Une semaine type, du lundi au vendredi

Rien ne fait mieux comprendre un métier que de le suivre heure par heure. Voici une semaine réaliste d'un coordinateur de projet IA à temps partiel — car ce rôle est presque toujours à temps partiel — dans une PME romande d'une quarantaine de personnes, en pleine phase de lancement d'un projet avec un prestataire externe. Aucun de ces blocs n'est théorique : ce sont les tâches que vous produirez vraiment.

**Lundi — Écouter le métier.** Vous passez une heure avec les deux personnes qui font aujourd'hui, à la main, la tâche qu'on veut outiller. Vous ne parlez pas d'IA : vous les regardez travailler, vous notez chaque étape, chaque exception, chaque cas tordu. « Et quand le client écrit en allemand, tu fais comment ? » « Et si la commande a déjà été livrée ? » Ces détails, invisibles depuis un bureau de direction, sont exactement ce que le prestataire doit connaître pour ne pas livrer un outil inutile. Vous êtes en train de constituer la matière première de votre cahier des charges.

**Mardi — Le point prestataire.** Réunion d'une heure avec l'agence qui développe la solution. Ils vous montrent une première version. Votre travail n'est pas d'admirer : c'est de confronter ce qu'ils montrent à ce que vous avez vu lundi. « Vous avez prévu le cas de la commande déjà livrée ? Non ? Alors ça ne marchera pas une fois sur cinq. » Vous jouez l'avocat du réel face à une démonstration toujours un peu trop belle. Vous repartez avec une liste d'écarts à corriger, écrite noir sur blanc.

**Mercredi — Arbitrer et remonter à la direction.** Le prestataire vous a annoncé que traiter les demandes en allemand doublerait le délai et le coût. Arbitrage. Vous pesez : combien de demandes sont en allemand ? Quel gain réel ? Vous tranchez pour une première version en français seulement, l'allemand en phase 2. Puis trente minutes avec la direction pour valider ce choix, expliqué en langage de dirigeant : « On livre plus vite et moins cher sur 80 % des cas, on garde l'allemand pour plus tard. » Vous parlez périmètre, délai et budget, jamais technique.

**Jeudi — Préparer le pilote.** Le projet approche du test grandeur nature. Vous choisissez trois personnes du métier pour l'essayer sur de vrais dossiers, vous définissez ce qu'on va mesurer — temps gagné, taux d'erreur, satisfaction des utilisateurs — et vous préparez une fiche simple pour recueillir leurs retours. Un pilote qui ne mesure rien ne prouve rien ; vous refusez de lancer sans instruments.

**Vendredi — Documenter et cadencer.** Une heure pour mettre à jour vos documents : le cahier des charges enrichi des cas vus lundi, le tableau de suivi des écarts, le planning. Rien de long — des documents courts, à jour, que tout le monde peut lire. Vous êtes la mémoire du projet : sans vous, chacun se souvient d'une version différente de ce qui a été décidé, et les malentendus prospèrent.

📌 Ce qui saute aux yeux quand on découvre le métier de l'intérieur : il est fait à **80 % de conversations, d'écoute du terrain, d'arbitrages et de documentation courte**, et à 20 % seulement de contact avec la technique — et encore, jamais pour coder, toujours pour cadrer et contrôler. Vous ne construisez rien de vos mains. Vous faites circuler l'information juste entre des gens qui ne se parleraient pas sans vous.

Au-delà de la semaine, il y a un rythme de projet qu'il faut apprendre à sentir. Un projet IA en PME dure typiquement de deux à six mois, et il passe par des phases nettes : cadrage, choix du prestataire, développement, pilote, déploiement. Chaque phase a son piège. Le cadrage bâclé fait dériver tout le reste. Le choix du prestataire mal instruit vous enchaîne à un mauvais partenaire. Le pilote escamoté vous fait déployer à l'aveugle un outil qui ne marche pas. Le professionnel sait où il en est dans cette trajectoire et ne brûle jamais une étape pour aller plus vite — car chaque étape sautée revient plus tard, plus chère.

Notez aussi ce que cette semaine n'est PAS. Ce n'est pas une semaine passée derrière un écran à « faire de l'IA ». ⚠️ Le débutant croit que piloter un projet IA, c'est manipuler l'outil ; il s'enferme dans la technique et néglige les conversations qui, seules, font avancer le projet. Le professionnel sait que sa valeur est ailleurs : dans l'heure passée avec le métier le lundi, dans la question gênante posée au prestataire le mardi, dans l'arbitrage assumé le mercredi. 💡 La règle tacite : sur un projet IA, ce sont les conversations que personne n'aime avoir — dire au prestataire que sa démo ne tient pas, dire à la direction qu'il faut réduire le périmètre — qui sauvent le projet. Les fuir, c'est le condamner en silence.

## Vos quatre interlocuteurs — et ce que chacun attend vraiment

Vous êtes à un carrefour. Quatre mondes qui, dans une PME, ne se parlent presque jamais, convergent tous vers vous — et chacun attend quelque chose de différent, parfois de contradictoire. Savoir ce que chacun veut vraiment, derrière ce qu'il dit, est la moitié du métier.

**La direction.** Elle a l'idée, le budget et l'impatience. Ce qu'elle demande à voix haute : « C'est pour quand, et combien ça coûte ? » Ce qu'elle veut au fond : la certitude que l'argent produira un retour visible et que l'entreprise ne prend pas de retard sur ses concurrents. Son biais typique est de sous-estimer la complexité — « c'est juste un petit outil, ça doit être rapide » — et de vouloir tout, tout de suite. Votre rôle avec elle : traduire le projet en langage de dirigeant — coût, délai, retour, risque — et surtout tempérer ses attentes sans casser son élan. Un dirigeant à qui vous promettez la lune pour ne pas le décevoir vous le reprochera trois mois plus tard, quand la lune ne sera pas là.

**Le métier et les utilisateurs.** Ce sont les gens dont vous voulez outiller le travail, et qui devront se servir de l'outil au quotidien. Ce qu'ils veulent vraiment : qu'on ne leur complique pas la vie, qu'on ne les remplace pas, et qu'on tienne compte de la réalité de leur travail — pas d'une version idéalisée vue d'en haut. Ils détiennent une connaissance que personne d'autre n'a : les cas particuliers, les exceptions, les « ça ne marche jamais comme ça en vrai ». ⚠️ Les ignorer au cadrage est l'erreur la plus coûteuse du métier : vous livrez alors un outil élégant qui échoue sur le premier cas réel, et vous perdez leur confiance pour de bon. Votre travail : les écouter tôt, longuement, et faire d'eux les co-auteurs du projet plutôt que ses victimes.

**Le prestataire technique.** C'est l'agence, le développeur indépendant ou le fournisseur qui construit la solution. Il connaît la technique mieux que vous — c'est pour cela qu'on le paie —, mais il a des biais qu'il faut connaître. Il veut livrer ce qui l'arrange techniquement, pas forcément ce dont vous avez besoin ; il a tendance à sur-promettre pour décrocher le contrat, puis à découvrir des complications ; et il parlera volontiers un jargon qui vous impressionne et vous fait lâcher prise. Ce qu'il attend : un cahier des charges clair — cela lui simplifie la vie autant qu'à vous — et un client qui paie et renouvelle. Votre travail : exploiter son expertise sans lui abandonner les décisions qui reviennent au métier, et refuser toute réponse que vous ne comprenez pas.

**La direction informatique ou le responsable des données**, quand il existe. Dans une PME, c'est parfois une personne externe ou un rôle partiel. Lui pense sécurité, données et cohérence avec les outils existants. Ce qu'il veut : qu'aucune donnée sensible ne parte dans une solution non validée, et que le nouveau système s'intègre sans casser le reste. Le court-circuiter, c'est s'exposer à un veto tardif qui bloque tout au dernier moment. Votre travail : l'associer dès le cadrage, surtout dès qu'il est question de données clients.

📌 L'erreur classique du débutant est de croire que ces interlocuteurs veulent la même chose. Ils ne veulent pas la même chose. La direction veut de la vitesse et du retour, le métier veut qu'on respecte son travail, le prestataire veut un contrat confortable, l'IT veut de la sécurité. Vous êtes le seul point de l'organisation où ces tensions se rencontrent. Votre valeur ne vient pas de ce que vous savez faire techniquement — elle vient de votre capacité à tenir ces fils en même temps sans qu'aucun ne casse.

Un exemple concret du grand écart de langage. Le même mardi, vous pouvez avoir deux conversations sur le même projet. À 9h, la direction : « Alors, on est dans les temps ? » — vous répondez en jalons et en francs : « Le développement est à 70 %, on lance le pilote dans deux semaines, on reste dans le budget de CHF 15'000. » À 14h, une utilisatrice inquiète : « Ce nouveau truc, ça va encore changer ma façon de bosser ? » — et là, ni jalon ni budget : « Justement, je veux qu'on le construise avec toi. Montre-moi les cas où ton travail est le plus pénible, c'est ça qu'on veut soulager, pas t'en rajouter. » Deux mondes, deux langues, le même projet. 💡 Le savoir-faire tacite : face à chacun, reformulez son intérêt dans SES mots avant de proposer quoi que ce soit. À la direction vous parlez retour et délai, au métier vous parlez respect de son travail, au prestataire vous parlez cahier des charges clair, à l'IT vous parlez données protégées. Celui qui ne sait parler qu'une langue — souvent celle de la technologie — perd trois interlocuteurs sur quatre.

## Ce que vous produisez réellement : vos quatre livrables

Un métier se juge à ses livrables. Ceux du coordinateur de projet IA sont peu nombreux, concrets et réutilisables d'un projet à l'autre — ce qui en fait, pour vous qui débutez, la matière première de votre futur portfolio. Il y en a quatre, et ils forment un système qui couvre tout le cycle du projet.

**1. Le cahier des charges.** C'est le document fondateur, celui qui transforme un souhait en commande précise. Il tient sur quelques pages et répond à des questions simples : quel problème résout-on, pour qui, quel résultat attend-on, dans quel périmètre — et surtout, qu'est-ce qui N'est PAS dans le projet. Il décrit les cas réels, y compris les exceptions vues sur le terrain, et il fixe les critères de succès mesurables. Le débutant écrit un cahier des charges vague — « une solution IA moderne et performante pour le service client » — qui laisse le prestataire livrer n'importe quoi de conforme à la lettre et d'inutile dans les faits. Le professionnel écrit un cahier des charges si concret qu'un prestataire ne peut pas se tromper sur ce qu'on attend de lui. 📌 Règle d'or : tout ce qui n'est pas écrit dans le cahier des charges finira en malentendu, en surcoût ou en dispute. Ce document est votre meilleure protection.

**2. La grille d'évaluation des prestataires.** Vous allez comparer plusieurs offres, et l'enthousiasme d'une belle démonstration est le pire des guides. La grille met tous les candidats sur les mêmes critères, notés de la même façon : compréhension de votre besoin, expérience sur des cas comparables, clarté des explications, traitement des données et sécurité, prix, délai, ce qui se passe après la livraison — maintenance, support, dépendance. ⚠️ Le critère le plus négligé et le plus décisif : que se passe-t-il si vous voulez changer de prestataire dans deux ans ? Un fournisseur qui vous enferme dans sa solution propriétaire, sans que vous puissiez récupérer vos données ou reprendre la main, est un risque majeur, quelle que soit la qualité de sa démo. La grille vous force à comparer ce qui compte vraiment, pas ce qui brille.

**3. Le plan de pilote.** On ne déploie jamais un projet IA en grand d'un coup. On le teste d'abord à petite échelle, sur de vrais dossiers, avec quelques utilisateurs, pendant quelques semaines. Le plan de pilote définit qui teste, sur quoi, pendant combien de temps, et — le cœur du document — ce qu'on mesure pour décider si l'on continue, si l'on corrige ou si l'on arrête. Un bon plan de pilote fixe d'avance les critères de réussite, avant de connaître le résultat, pour ne pas se raconter d'histoires ensuite. Le débutant saute le pilote « pour aller plus vite » et déploie à l'aveugle ; le professionnel sait que quelques semaines de pilote économisent des mois de dégâts et des milliers de francs jetés dans un outil que personne n'utilisera.

**4. Le tableau de retour sur investissement.** On ne pilote pas ce qu'on ne chiffre pas. Ce tableau met face à face, en francs, ce que le projet coûte — développement, licences, temps de pilotage, formation — et ce qu'il rapporte : temps gagné valorisé, erreurs évitées, capacité libérée pour des tâches à plus forte valeur. Il n'a pas besoin d'être un chef-d'œuvre comptable ; il a besoin d'être honnête et lisible par la direction. ⚠️ Le piège classique : ne compter que le coût du logiciel et oublier les coûts cachés — le temps du métier pour tester, la formation, la maintenance annuelle, votre propre temps de pilotage. Un ROI qui ignore ces coûts est un mensonge rassurant qui explose au premier bilan.

Un mot sur un cinquième document, informel mais précieux : le **journal de décisions**. Ce n'est pas un livrable officiel, c'est votre carnet où vous notez chaque choix important avec sa date et sa raison — « le 12 mars, on a décidé de reporter l'allemand en phase 2 pour tenir le budget ». Ce carnet vous sauve dans les moments de tension, quand quelqu'un demande « mais pourquoi on n'a pas fait l'allemand ? » : vous ressortez la décision, sa raison, et la personne qui l'a validée. Sur un projet qui dure des mois et implique quatre interlocuteurs aux mémoires divergentes, ce simple journal évite la moitié des conflits.

📌 Ces quatre livrables s'enchaînent : le cahier des charges permet d'évaluer les prestataires, la grille choisit le bon, le pilote vérifie que ce qu'il a livré marche vraiment, et le tableau de ROI dit si tout cela valait la peine. 💡 Un dernier repère de pro : chacun de ces documents doit rester court et concret. Un cahier des charges de quarante pages que personne ne lit protège moins bien qu'une page précise que tout le monde a comprise et signée.

## Cas chiffré : la PME de logistique genevoise

Passons du principe au concret avec un cas représentatif du tissu romand. Une PME de logistique genevoise de 35 personnes reçoit chaque jour des dizaines de demandes clients par e-mail : suivis de colis, réclamations, questions de facturation. Deux collaboratrices y passent l'essentiel de leurs matinées à trier, qualifier et rédiger les premières réponses. La direction, convaincue que « l'IA peut faire ça », débloque un budget et vous confie le projet. Voici le raisonnement chiffré que vous posez, et qui est exactement celui que ce cours vous apprend à produire.

📌 **Le coût du problème actuel.** Deux personnes consacrent environ 3 heures par jour chacune au tri et au premier jet des réponses, soit 6 heures quotidiennes, environ 30 heures par semaine. À un coût horaire chargé prudent de CHF 55, cela représente de l'ordre de CHF 1'650 par semaine, soit près de CHF 80'000 par an mobilisés sur une tâche répétitive. *(chiffres illustratifs, à ajuster au cas réel)*

📌 **Le cadrage du projet.** Plutôt que « automatiser le service client », vous cadrez serré : un outil qui classe automatiquement les demandes entrantes par type et rédige un premier jet de réponse pour les trois catégories les plus fréquentes et les plus standard — suivi de colis, accusé de réception, demande de document. Les cas complexes ou sensibles restent traités à la main. Ce périmètre restreint, décidé avec les deux collaboratrices, est ce qui rend le projet réaliste et sûr.

📌 **Le coût du projet.** Vous consultez trois prestataires avec votre grille. Les offres vont de CHF 9'000 à CHF 35'000. Vous écartez la plus chère, brillante mais qui vous enfermerait dans une solution propriétaire, et retenez une offre à CHF 14'000 incluant le développement et trois mois de support. À cela s'ajoutent une licence annuelle d'environ CHF 3'000, quelques jours de votre temps de pilotage valorisés autour de CHF 4'000, et le temps du métier pour tester. Coût de première année : de l'ordre de CHF 22'000. *(ordres de grandeur illustratifs)*

📌 **Le gain estimé.** L'outil ne supprime pas le travail humain — les réponses sont toujours relues et envoyées par les collaboratrices — mais il fait passer le traitement d'une demande standard de plusieurs minutes à moins d'une. Estimation prudente après pilote : 40 % du temps consacré à cette tâche libéré, soit environ 12 heures par semaine, à peu près CHF 30'000 par an de capacité rendue — réinvestie dans le suivi proactif des clients et la réduction des litiges.

📌 **Le retour.** Un investissement de première année d'environ CHF 22'000 libère une capacité annuelle de l'ordre de CHF 30'000, récurrente et croissante une fois la licence seule à payer les années suivantes. Le projet se rembourse dans l'année, puis tourne à l'avantage de l'entreprise. Mais le chiffre le plus important n'est pas là : les deux collaboratrices, soulagées de la corvée, deviennent les meilleures ambassadrices de l'outil, et la direction obtient la preuve qu'un projet IA bien piloté rapporte — ce qui débloquera les suivants.

📌 **Le contre-exemple qui coûte cher.** Imaginons l'autre scénario, celui où personne ne cadre ni ne pilote. La direction, séduite par une démonstration, signe directement avec le prestataire à CHF 35'000, sans cahier des charges précis ni pilote. Le prestataire livre un outil impressionnant qui, faute d'avoir connu les cas réels, se trompe une fois sur trois et répond à côté sur les réclamations sensibles. Les collaboratrices, jamais consultées, se méfient de l'outil et retournent à leur méthode. Six mois plus tard, l'outil est abandonné, CHF 35'000 plus la licence sont perdus, et l'entreprise a acquis la conviction durable que « l'IA, ça ne marche pas chez nous » — une méfiance qui rendra le prochain projet deux fois plus difficile. Le coût réel d'un projet raté n'est jamais seulement le budget perdu : c'est le capital de confiance brûlé. C'est précisément ce que la coordination évite.

Ce cas illustre le déplacement mental que tout le métier exige. Le débutant, ou la direction non accompagnée, mesure un projet à la beauté de la démonstration et signe au montant le plus impressionnant. La professionnelle le mesure au problème réellement résolu, cadre serré, met les offres en concurrence sur une grille, vérifie par un pilote, et raconte le tout à la direction en francs. 💡 Le savoir-faire tacite, ici : le meilleur projet IA n'est presque jamais le plus ambitieux ni le plus cher, c'est le mieux cadré. Un petit périmètre bien résolu vaut infiniment mieux qu'un grand rêve à moitié livré — et il ouvre la porte au suivant, par la preuve plutôt que par la promesse.

## Les erreurs de débutant

Presque tous ceux qui découvrent ce métier commettent les mêmes fautes dans les premiers projets. Elles ne viennent pas d'un manque d'intelligence, mais d'une intuition fausse : celle qu'un bon outil, confié à un bon prestataire, produira forcément un bon résultat. Les connaître d'avance, c'est éviter des mois perdus et des milliers de francs.

⚠️ **Sauter le cadrage.** Pressé de « lancer le projet », le débutant confie au prestataire un besoin vague et le laisse interpréter. Le prestataire, de bonne foi, construit ce qu'il a compris — c'est-à-dire autre chose que ce dont vous aviez besoin. On ne le découvre qu'à la livraison, quand il est trop tard et trop cher de corriger. Le cadrage n'est jamais du temps perdu : c'est le temps qui économise tout le reste.

⚠️ **Se laisser intimider par le jargon.** Face à un prestataire qui aligne les termes techniques, le débutant hoche la tête pour ne pas passer pour ignorant, et accepte des affirmations qu'il ne comprend pas. À partir de là, il a perdu le contrôle : il ne peut plus challenger ni arbitrer. Le professionnel assume de dire « je ne comprends pas, expliquez-moi simplement ce que ça change pour nous » — et un prestataire incapable de le faire est un signal d'alarme.

⚠️ **Choisir le prestataire sur la démonstration.** Une belle démo est un spectacle préparé sur des cas idéaux. Le débutant, séduit, signe. Le professionnel sait qu'une démonstration ne dit rien de ce qui se passera sur vos vrais dossiers, avec vos exceptions et vos données ; il compare sur une grille, demande des références sur des cas comparables, et interroge l'après-vente autant que le produit.

⚠️ **Oublier les utilisateurs au cadrage.** Le débutant cadre le projet depuis un bureau, avec la direction, sans passer une heure auprès de ceux qui font la tâche à la main. Il livre alors un outil qui échoue sur le premier cas réel — celui que seuls les gens du terrain connaissaient. Consulter les utilisateurs tôt n'est pas une politesse, c'est la seule façon de connaître le vrai travail.

⚠️ **Sauter le pilote.** Pour aller plus vite ou pour rassurer une direction pressée, le débutant déploie directement en grand. Si l'outil a un défaut — et tout outil neuf en a —, il le découvre auprès de toute l'entreprise à la fois, dans le pire des contextes. Quelques semaines de pilote sur trois personnes auraient révélé le problème à moindre coût et à l'abri des regards.

⚠️ **Ne pas définir les critères de succès à l'avance.** Sans critères fixés avant le pilote, on juge le résultat à l'humeur du moment et à la voix la plus forte dans la salle. Le professionnel écrit noir sur blanc, avant de lancer, ce qui comptera comme une réussite — un temps gagné, un taux d'erreur acceptable, une satisfaction minimale — pour que la décision de continuer ou d'arrêter soit honnête.

⚠️ **Ignorer les coûts cachés.** Le débutant ne retient que le prix du logiciel et annonce à la direction un budget qui explose ensuite : il avait oublié la licence annuelle, la maintenance, la formation, le temps du métier pour tester, son propre temps de pilotage. Un budget crédible additionne tous ces postes dès le départ.

⚠️ **Sous-estimer la dépendance au prestataire.** Enthousiaste, le débutant ne se demande jamais ce qui se passera si le prestataire augmente ses prix, fait faillite ou devient injoignable. Il découvre trop tard qu'il ne peut ni récupérer ses données, ni reprendre la main, ni changer de fournisseur. Poser la question de la sortie AVANT de signer est une discipline élémentaire trop souvent oubliée.

⚠️ **Vouloir tout, tout de suite.** Porté par l'enthousiasme et une direction ambitieuse, le débutant élargit le périmètre à chaque réunion : « et si ça faisait aussi ceci, et cela ». Le projet devient une usine à gaz, dérape en délai et en coût, et ne livre finalement rien. La discipline du professionnel est de dire non, de tenir un périmètre serré, et de renvoyer les bonnes idées à une phase 2 qui n'existera peut-être jamais — et ce n'est pas grave.

📌 Un fil relie toutes ces erreurs : la précipitation. Le débutant veut du résultat vite et brûle les étapes de méthode — cadrer, questionner, comparer, tester. Le professionnel sait que sur un projet IA, la lenteur du début est la vitesse de la fin : chaque heure investie dans le cadrage et le pilote évite des semaines de correction. Aller vite, ici, c'est prendre le temps de bien commencer.

## La posture : le pont, pas le camp

Tout le métier tient dans une tension : vous êtes payé par la direction, mais un projet ne réussit que si le métier l'adopte et si le prestataire livre juste. Vous servez plusieurs maîtres aux intérêts divergents, et aucun ne vous obéit. Résoudre cette tension en choisissant un camp — devenir le bras armé de la direction pour presser le métier, ou l'avocat du métier contre la direction, ou le relais docile du prestataire — condamne le projet. La seule posture qui marche est celle du pont : rester le point qui relie sans appartenir. Cela paraît inconfortable ; c'est pourtant tout votre savoir-faire.

Premier principe : **partir du problème, jamais de la solution.** N'arrivez jamais en disant « on va mettre de l'IA ». Arrivez en demandant « quel est le problème qui nous coûte le plus cher ou le plus de temps ? », et vérifiez que l'IA est bien la meilleure réponse — parfois elle ne l'est pas, et un projet honnête peut conclure qu'un simple changement de processus suffit. Un coordinateur qui part de la solution cherche un problème à sa technologie ; un coordinateur qui part du problème trouve la bonne solution, IA ou non. C'est ce renversement qui vous rend crédible auprès du métier comme de la direction.

Deuxième principe : **protéger le périmètre.** Vous serez poussé de toutes parts à en faire plus — la direction rêve grand, le prestataire propose des options, chacun a sa bonne idée. Votre rôle est de tenir la ligne, car un périmètre qui gonfle est la première cause de projet noyé. Dire non aux bonnes idées pour sauver le projet est l'un des gestes les plus difficiles et les plus utiles du métier. Le professionnel note ces idées dans une phase ultérieure, remercie, et referme la porte du présent.

Troisième principe : **exiger le langage clair, refuser le flou.** Face au prestataire, chaque fois qu'une réponse reste vague — « ça devrait marcher », « c'est assez précis », « on verra à l'usage » —, creusez jusqu'à obtenir du concret et du chiffré. Le flou dans les mots devient toujours du flou dans le résultat, et une facture au bout. Votre ignorance technique est ici une force : elle vous autorise à demander qu'on vous explique tout simplement, encore et encore, jusqu'à ce que ce soit clair pour vous — et donc pour tout le monde.

Quatrième principe : **assumer d'être le porteur de la mauvaise nouvelle.** C'est vous qui direz à la direction qu'il faut réduire le périmètre, au prestataire que sa livraison ne tient pas, au métier qu'il devra changer un peu ses habitudes. Personne n'aime ce rôle, et le débutant le fuit en enjolivant tout — puis le projet déraille pour de bon. Le professionnel sait qu'une vérité inconfortable dite tôt vaut mille bonnes nouvelles fausses. Sa crédibilité vient précisément de sa fiabilité : quand il dit que ça va, on le croit, parce qu'il a su dire quand ça n'allait pas.

◆ **Le savoir-faire que personne ne vous apprend.** Face à la direction, vous êtes l'avocat du réel : vous la protégez de ses propres rêves de calendrier et de périmètre. Face au métier, vous êtes l'avocat du changement utile : vous montrez le gain concret et respectez la connaissance du terrain. Face au prestataire, vous êtes le gardien de l'intérêt de l'entreprise : vous exploitez son expertise sans lui abandonner vos décisions. Vous tenez ces rôles en même temps, et c'est inconfortable. Cet inconfort n'est pas un défaut de votre position : il EST votre position. Le jour où vous cessez de servir un camp contre les autres pour devenir le pont entre tous, vous faites vraiment le métier.

Un mot, enfin, sur votre positionnement professionnel. Ce rôle s'exerce le plus souvent **en interne**, en extension d'un poste de responsable, de chef de projet ou de coordinateur. Mais un marché s'ouvre en Suisse romande pour des intervenants **externes** qui pilotent des projets IA pour plusieurs PME, là où aucune n'a les moyens d'un poste dédié ni la méthode en interne. Si vous empruntez cette voie, quelques repères, à confirmer sur votre marché : un forfait de cadrage et de choix de prestataire se chiffre en milliers de francs, et une journée de pilotage se facture souvent entre CHF 900 et 1'500. Côté statut, l'indépendant relève de la raison individuelle, avec affiliation à l'AVS et assujettissement à la TVA au-delà de CHF 100'000 de chiffre d'affaires annuel — sujets traités en détail dans le cursus IA-14. 💡 Mais quelle que soit la voie, la compétence qui fait votre valeur n'est jamais la maîtrise technique : c'est votre capacité à transformer un besoin flou en projet livré, en tenant ensemble des gens qui ne se parlent pas. Les outils changeront ; cette compétence, elle, ne se démodera pas.