# Piloter un projet IA sans être développeur

> 4 modules · 10 leçons · ~10 h d'étude · Attestation — SFM Academy (successfor-me.ch).
>
> Résumé public leçon par leçon. Le contenu pédagogique complet (hors 1re leçon gratuite) est réservé aux abonnés.

Fiche du cours : https://successfor-me.ch/academy/cours/fiche/IA-18

## Leçon 1 — Le métier de coordinateur de projet IA : rôle et interlocuteurs

**À 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.

## Leçon 2 — Traduire un besoin métier en cahier des charges clair

**À retenir :**

- Le livrable du pilote non-technique n'est pas du code, c'est le cahier des charges : le document qui transforme une demande floue en projet borné, chiffrable et évaluable. Une heure de cadrage économise des semaines de développement dans la mauvaise direction.
- Un CDC utile tient sur deux à quatre pages et répond à huit questions dans un ordre d'entonnoir : contexte, problème chiffré, objectif mesurable, périmètre IN, périmètre OUT, données disponibles, contraintes, critères de succès, livrables.
- Le vrai besoin ne se donne jamais spontanément : on l'extrait en interviewant ceux qui font (pas seulement ceux qui décident), en faisant raconter le déroulé concret d'une journée, et en appliquant les cinq pourquoi pour passer de la solution imaginée à la douleur réelle.
- La solution proposée par le client (« il me faut un chatbot ») est une hypothèse à vérifier, jamais un cahier des charges. Le besoin est toujours en dessous, et il se chiffre.
- Un objectif mesurable a quatre composantes : indicateur, cible, base de comparaison, délai. Pour l'IA, on fixe un seuil de qualité acceptable (jamais 100 %) et le comportement en cas d'incertitude : ne rien inventer, escalader vers l'humain.
- Le périmètre OUT est aussi important que le IN : écrire ce qu'on ne fait pas ferme la porte au glissement de périmètre qui fait exploser budget et délai, et prépare la vente d'une phase 2.
- Trois erreurs ruinent un CDC — le jargon technique imposé, l'objectif non mesurable, le périmètre flou — et viennent toutes du même inconfort face au vide, comblé maladroitement par du jargon, des adjectifs ou des promesses.
- Le savoir-faire central : un bon CDC dit ce qu'on veut, pas comment le faire. Le « quoi » appartient au pilote, le « comment » à la technique. Un CDC réussi peut aller à trois prestataires et revenir avec trois approches valables.

**Plan de la leçon :** La phrase qui coûte le plus cher : « on veut de l'IA pour gagner du temps » · Anatomie d'un cahier des charges utile : les huit blocs · Interviewer le métier : extraire le vrai besoin · Écrire des critères de succès mesurables · Walkthrough : d'une demande floue à un CDC, cas SanitaPro SA · La trame de CDC à réutiliser · Les trois erreurs qui ruinent un cahier des charges · Le savoir-faire tacite : dire ce qu'on veut, pas comment le faire

_Contenu complet réservé aux abonnés — [suivre ce cours](https://successfor-me.ch/academy/cours/fiche/IA-18)._

## Leçon 3 — Cas chiffré : un projet IA de A à Z dans une PME vaudoise

**À retenir :**

- Un projet IA ne part JAMAIS de l'outil, mais d'une douleur unique, mesurée et chiffrée en CHF. Ici : 6 h/jour de retranscription, soit une embauche à 0,5 EPT (~CHF 35'000/an) à éviter.
- Le cahier des charges d'un non-développeur tient en 3-4 pages : besoin en une phrase, périmètre ET hors-périmètre, exigences non négociables, critères de succès mesurables, contraintes d'intégration décrites en langage métier.
- En secteur médical, la conformité (LPD, secret médical art. 321 CP, hébergement des données) est un critère d'ÉLIMINATION, pas une formalité. La démo montre le meilleur visage de l'outil ; le contrat et ses annexes montrent le vrai.
- Trois devis se comparent avec une grille pondérée décidée AVANT de lire les prix. Le moins cher se disqualifie souvent tout seul sur les critères non négociables.
- Le pilote répond à UNE question avec des critères de sortie fixés à l'avance. Un mauvais résultat en semaine 2 (jargon massacré) est une donnée à diagnostiquer — défaut de réglage vs défaut structurel — pas un verdict d'échec.
- Le déploiement meurt par l'humain, pas par la technique. La résistance ne se casse pas : elle se retourne en donnant à la personne un rôle plus valorisant (dactylo → relectrice-référente qualité).
- Budgéter DEUX budgets : mise en place (one-off) et récurrent (annuel), et raisonner en coût sur 3 ans (TCO). Prévoir 20-25 % de contingence — le dépassement classique vient de l'adaptation au vocabulaire de l'entreprise.
- Le ROI ne se mesure qu'à la fin, en valeur RÉ-ALLOUÉE (embauche évitée, service amélioré), jamais en heures abstraites. Un projet se juge à trois nombres tenus ensemble — budget, délai, valeur — et à la franchise du bilan.

**Plan de la leçon :** Le décor et le besoin : chiffrer une douleur avant d'en faire un projet · Le cahier des charges : traduire une douleur en spécifications sans jargon · Le choix du prestataire : trois devis, une grille, et un piège LPD · Le pilote : six semaines pour prouver la valeur en vrai · Le déploiement : la conduite du changement, ou le vrai chantier · Le budget réel : mise en place, récurrent, et le dépassement qu'on n'avait pas vu · Le délai réel vs prévu : pourquoi trois mois sont devenus cinq · Le bilan et le ROI mesuré : le tableau de suivi budget / délai / valeur

_Contenu complet réservé aux abonnés — [suivre ce cours](https://successfor-me.ch/academy/cours/fiche/IA-18)._

## Leçon 4 — Les 10 questions à poser à un prestataire technique

**À retenir :**

- Vous ne jugez pas la technologie, vous jugez la personne : les dix questions ne testent pas le savoir-faire technique du prestataire mais sa droiture, sa précision et sa maturité de partenaire. Assumer « je ne suis pas technicien, expliquez-moi simplement » est une arme, pas une faiblesse.
- Sur le périmètre et les données, exigez des bords nets : un bon prestataire nomme autant ce que l'outil ne fait pas que ce qu'il fait, et dit précisément où sont vos données, qui les lit et qu'elles restent les vôtres, par écrit. « Il fait tout » et « c'est dans le cloud » sont des alertes.
- « Que se passe-t-il quand ça se trompe, et comment on le voit ? » est la question la plus discriminante : un pro prévoit un filet, garde l'humain dans la boucle et rend l'erreur traçable ; « ça ne se trompe pas » disqualifie.
- On ne compare jamais deux projets IA sur le prix initial mais sur le coût total sur trois ans — développement, coût à l'usage des services d'IA, hébergement, maintenance, formation. Un prix rond et bas cache presque toujours des récurrents ou un périmètre rogné.
- La réversibilité et la propriété préservent votre pouvoir : exigez de pouvoir récupérer vos données dans un format standard, de détenir la documentation, et de savoir qui possède le code, les paramétrages et les résultats. Un fournisseur dont on ne peut pas partir n'est plus un fournisseur.
- Références comparables, délai jalonné et conformité traitée avant la signature : appelez un vrai client de taille proche et demandez ce qui a mal tourné ; méfiez-vous du délai magique sans phase de test ; exigez que la protection des données soit cadrée en amont (détail réglementaire en IA-19).
- Le savoir-faire tacite : la question qui gêne le prestataire est presque toujours la plus utile. La gêne pointe l'endroit où ses intérêts divergent des vôtres — retournez-y calmement au lieu de changer de sujet par politesse.
- Écoutez la forme autant que le fond : le bon prestataire dit « ce qu'il ne fait pas », « quand ça se trompe », « c'est à vous » ; le vendeur de rêve dit « ne vous inquiétez pas », « tout », « ça marche tout seul ». Ces tics de langage sont un test à eux seuls.

**Plan de la leçon :** Pourquoi dix questions valent mieux qu'un cahier des charges parfait · Question 1 — le périmètre, et Question 2 — les données · Question 3 — quand ça se trompe, et Question 4 — la maintenance · Question 5 — le coût total, et Question 6 — la réversibilité · Question 7 — les références, et Question 8 — le délai réaliste · Question 9 — la conformité, et Question 10 — la propriété du résultat · Mini-dialogue : le bon prestataire et le vendeur de rêve, à l'oreille · Le savoir-faire tacite : la question qui gêne est presque toujours la plus utile

_Contenu complet réservé aux abonnés — [suivre ce cours](https://successfor-me.ch/academy/cours/fiche/IA-18)._

## Leçon 5 — Découper en pilote délimité plutôt qu'en grand projet

**À retenir :**

- Les grands projets IA échouent dans le tunnel : on engage tout le budget avant d'avoir la moindre preuve, et on ne découvre qu'à la fin — trop tard — si l'idée marchait sur ses vraies données.
- Un pilote délimité tient sur cinq conditions non négociables : un seul cas, un périmètre étroit et nommé, une durée courte fixée d'avance, un critère de succès chiffré posé avant de lancer, et des données propres déjà disponibles.
- Le principe directeur est « prouver la valeur avant de scaler » : on apprend d'abord à l'échelle la plus petite et la moins coûteuse, on décide d'étendre ensuite, sur la preuve — pas l'inverse.
- Le vrai produit d'un pilote n'est pas un outil qui tourne, c'est une décision : go (on étend), no-go (on arrête et on a économisé une fortune), ou pivot (on redélimite sur le cas voisin découvert). Les trois issues sont des succès de pilotage.
- Découper un grand projet, c'est le transformer en une suite de pilotes dont chacun prouve sa valeur avant de financer le suivant — on choisit chaque cas selon valeur, fréquence et faisabilité des données.
- Trois conditions matérielles font ou défont un pilote : la matière (données propres et accessibles tout de suite), les gens (des volontaires curieux, pas des sceptiques désignés), et le compteur (une mesure décidée avant de lancer).
- Trois erreurs de découpage à repérer par leur signature : trop large (le « et aussi » qui fait regonfler le grand projet), sans critère (la décision finale se joue à l'affect), sans données (le temps part en nettoyage, on ne teste jamais l'idée).
- Le savoir-faire qui résume tout : un pilote qui réussit à petite échelle vaut mille promesses — un fait modeste et chiffré sur vos données écrase la plus belle démonstration d'un fournisseur.

**Plan de la leçon :** Le grand projet IA échoue dans le tunnel — et on ne le sait qu'à la fin · Le pilote délimité : cinq conditions non négociables · Prouver la valeur avant de scaler : la logique de l'éclaireur · Le pilote comme outil de décision : go, no-go, pivot · Walkthrough : découper un grand projet en pilote · Les conditions d'un bon pilote : données, volontaires, mesure · Les erreurs de découpage : trop large, sans critère, sans données

_Contenu complet réservé aux abonnés — [suivre ce cours](https://successfor-me.ch/academy/cours/fiche/IA-18)._

## Leçon 6 — Mesurer et présenter le ROI à une direction : le tableau qui convainc

**À retenir :**

- Une direction décide sur un chiffre clair qu'elle a compris ET qu'elle croit — jamais sur un rapport de vingt pages ni sur un ressenti comme « on gagne un temps fou ».
- Sans baseline (la mesure du AVANT, capturée avant le lancement), aucun gain n'est prouvable : c'est la seule erreur de la leçon qui est irréversible.
- Mesurez le gain sur quatre axes : temps et argent forment le corps du ROI, la qualité le protège de l'objection, la satisfaction en donne le contexte crédible.
- Un ROI honnête soustrait TOUS les coûts : licence, mise en place, consultant, formation, maintenance — dans le doute, chargez les coûts et allégez les gains.
- Séparez toujours les gains certains (temps mesuré, erreurs mesurées) des gains estimés (monétisation du temps libéré, conditionnée par une décision de direction).
- Le tableau qui convainc a une colonne « Statut » (certain / estimé) et s'ordonne du plus certain au plus estimé ; il tient sur un regard.
- La slide unique suit quatre temps : problème, ce qu'on a fait, résultat chiffré, recommandation avec une décision précise demandée.
- Votre crédibilité se dépense une seule fois : un premier ROI modeste mais tenu vaut plus qu'un ROI spectaculaire qui ne se matérialise pas.

**Plan de la leçon :** Le moment de vérité : le projet marche, mais la direction ne le voit pas · Définir les indicateurs AVANT : la baseline, ou pourquoi sans photo de départ vous n'avez rien · Mesurer le gain sur quatre axes : temps, argent, qualité, satisfaction · Calculer un ROI honnête : les gains face à TOUS les coûts, maintenance comprise · Gains certains contre gains estimés : la ligne qui sauve votre crédibilité · Le tableau qui convainc : walkthrough de construction · La slide unique : problème, action, résultat chiffré, recommandation · Les erreurs qui détruisent la crédibilité et le savoir-faire tacite à emporter

_Contenu complet réservé aux abonnés — [suivre ce cours](https://successfor-me.ch/academy/cours/fiche/IA-18)._

## Leçon 7 — Gérer un projet qui dérape : signaux d'alerte et arbitrages

**À retenir :**

- Le coordinateur est souvent le dernier à voir le dérapage, à cause du biais d'engagement : chaque signal remet en cause une de ses décisions, alors il réinterprète les mauvaises nouvelles en positif. La discipline consiste à regarder les signaux en face, tôt, quand ils coûtent encore peu à corriger.
- Six signaux d'alerte se lisent sans être technicien : délais qui glissent par petits pas, prestataire évasif qui répond en jargon à une question simple, périmètre qui gonfle (scope creep), données pas prêtes, utilisateurs absents, résultats décevants au pilote. Un signal isolé est du bruit ; quatre ou cinq allumés ensemble sont un message.
- Distinguez la mauvaise passe (empire puis se stabilise, problème d'exécution rattrapable) du vrai dérapage (chaque point de situation pire que le précédent, fondation attaquée). Jugez le film, pas la photo. Aucun surcroît d'effort ne répare une fondation absente (données, besoin, utilisateurs).
- Quatre arbitrages, à relier à la nature du problème : réduire le périmètre (scope creep ou ambition démesurée), prolonger avec un jalon daté et vérifiable (problème d'exécution précis), changer de prestataire (défaillance du prestataire, pas du projet), arrêter (fondation non réparable). Le mauvais réflexe universel est de n'avoir qu'un levier : prolonger.
- Le coût irrécupérable est le piège reine : l'argent déjà dépensé est perdu quoi qu'on fasse, il ne doit jouer aucun rôle dans la décision de continuer. Question qui désamorce : « Si ce projet arrivait aujourd'hui sur mon bureau, tel quel, est-ce que je le lancerais ? » Si non, la seule raison de continuer est une non-raison.
- On annonce une mauvaise nouvelle tôt et structurée : fait, cause, options chiffrées, recommandation. Jamais cacher ni minimiser. Ne jamais apporter un problème sans apporter des voies de sortie. Un arrêt présenté comme une décision de bonne gestion (et non comme une défaite) renforce la crédibilité au lieu de la détruire.
- Trois erreurs aggravent tout et se renforcent en spirale : ignorer les signaux, jeter plus d'argent sur le problème, cacher le problème à la direction. Casser la chaîne en un seul point — voir un signal, refuser d'ajouter du budget, ou annoncer tôt — suffit à éviter le désastre.
- La conviction à graver : arrêter ou réorienter à temps est une réussite de pilotage, pas un échec. Le projet sauvé n'est presque jamais le projet initial — c'est une version plus modeste et plus honnête. Livrer 40 % qui marchent vaut infiniment mieux que promettre 100 % qui ne viennent jamais.

**Plan de la leçon :** Pourquoi on ne voit pas déraper un projet qu'on pilote soi-même · Les six signaux d'alerte précoces qu'un néophyte doit savoir lire · Lire les signaux ensemble : mauvaise passe ou vrai dérapage ? · Les quatre arbitrages du coordinateur : réduire, prolonger, changer, arrêter · Arrêter sans vivre l'arrêt comme un échec : désamorcer le coût irrécupérable · Annoncer la mauvaise nouvelle à la direction sans se griller · Le cas Blanchard : un projet qui dérape, un redressement maîtrisé · Les trois erreurs qui aggravent tout, et la conviction à graver

_Contenu complet réservé aux abonnés — [suivre ce cours](https://successfor-me.ch/academy/cours/fiche/IA-18)._

## Leçon 8 — Négocier un devis IA sans se faire vendre l'inutile

**À retenir :**

- Un devis IA n'est pas un prix, c'est une liste d'engagements : derrière chaque ligne il y a un coût, une durée, un responsable et une dépendance. Rendez ces quatre choses explicites.
- Exigez la décomposition et séparez toujours les coûts uniques (cadrage, développement, intégration, tests) des coûts récurrents (maintenance, licences, consommation). Multipliez le mensuel par 36 : c'est le vrai devis.
- Les coûts récurrents cachés — consommation des modèles, licences de plateformes tierces, hébergement — se paient chaque mois. Les comptes des outils stratégiques doivent être au nom de VOTRE entreprise, pas du prestataire.
- Traquez trois superflus : les gadgets (fonctions que personne n'utilisera), la sur-ingénierie (robustesse démesurée face à votre volume réel), et la dépendance créée exprès (code jamais livré, comptes captifs, formats fermés).
- Négociez le périmètre et la valeur avant le prix : enlever le superflu réduit la facture sans dégrader la qualité, alors que raboter le total nu pousse le prestataire à se rattraper sur les tests et la maintenance.
- Ancrez la discussion dans la valeur créée (temps humain libéré, erreurs évitées) : elle vous dit jusqu'où la dépense est raisonnable. N'acceptez jamais un forfait opaque juste parce qu'il tient dans le budget.
- Le pilote payant transforme un pari en test : périmètre restreint mais réel, critères de réussite chiffrés et écrits d'avance, durée bornée, et un vrai droit d'arrêter sans pénalité à la fin.
- Le réflexe qui protège de tout : ce que vous ne comprenez pas dans un devis, vous le faites expliquer, ou vous ne le payez pas. La charge de l'explication pèse sur celui qui vend, jamais sur vous.

**Plan de la leçon :** Un devis IA est écrit pour que vous ne le compreniez pas · Anatomie d'un devis IA : décomposer les postes ligne par ligne · Les coûts récurrents cachés et les licences d'outils tiers · Repérer le superflu : gadgets, sur-ingénierie et dépendance · Négocier sur la valeur et le périmètre, pas seulement le prix · Le dialogue de négociation, mot pour mot · Le pilote payant : tester avant de s'engager · Les erreurs à ne pas commettre et le réflexe qui protège

_Contenu complet réservé aux abonnés — [suivre ce cours](https://successfor-me.ch/academy/cours/fiche/IA-18)._

## Leçon 9 — Les erreurs qui font échouer un projet IA piloté

**À retenir :**

- Les projets IA échouent presque toujours par le pilotage, pas par la technologie : cahier des charges, cadrage, données, choix des gens — tout se joue avant la première ligne de code.
- Un cahier des charges se valide quand l'expert métier le corrige et le contredit. Le silence poli n'est pas une validation : c'est le signal que le document est en jargon et que personne ne s'y reconnaît.
- Un critère de succès utile tient en une phrase avec une métrique, un chiffre et une date. Sans lui, le projet ne peut être ni gagné ni arrêté : il flotte dans le flou des opinions.
- L'IA n'a pas de bon sens : elle automatise les données qu'on lui donne, désordre compris. Faites toujours vérifier un échantillon de données par la personne métier avant de lancer un pilote.
- Un bon pilote est étroit, autonome et rapide. Le grand projet intégré multiplie les dépendances et repousse le premier résultat au moment le plus risqué — la fin.
- Comparez des coûts totaux, jamais des prix d'entrée. Le prestataire qui pose beaucoup de questions sur votre métier vaut mieux que celui qui répond le moins cher en une heure.
- La baseline se prend avant le déploiement, en quelques mesures simples, sinon le ROI est indémontrable après. On mesure l'avant tant qu'il est encore là.
- Les utilisateurs finaux détiennent le savoir tacite : impliquez-les dès le cadrage, faites-les réagir à des cas réels pour extraire les règles invisibles, sinon l'outil sera rejeté même s'il est techniquement bon.

**Plan de la leçon :** Pourquoi les projets IA échouent par le pilotage, pas par la technologie · Erreur 1 — Le cahier des charges en jargon technique : le métier ne se reconnaît pas · Erreur 2 — Pas de critère de succès mesurable : le projet ne peut pas être gagné · Erreur 3 — Le pilote lancé sur des données sales : on automatise le désordre · Erreur 4 — Le grand projet au lieu du pilote : tout miser d'un coup · Erreur 5 — Le prestataire choisi sur le prix seul : l'économie qui coûte cher · Erreur 6 — Pas de baseline avant : un ROI impossible à démontrer après · Erreur 7 — Ignorer les utilisateurs finaux jusqu'à la livraison

_Contenu complet réservé aux abonnés — [suivre ce cours](https://successfor-me.ch/academy/cours/fiche/IA-18)._

## Leçon 10 — Atelier : cahier des charges + grille d'évaluation de prestataire

**À retenir :**

- Un cahier des charges commence toujours par le problème chiffré, jamais par la solution ou l'outil.
- Un objectif utile a une valeur de départ, une valeur cible et une échéance : sinon il n'est pas mesurable.
- Le périmètre OUT (ce qui est exclu) protège du dérapage de facturation autant que le périmètre IN.
- La grille d'évaluation pondérée compare les offres sur VOS priorités : compréhension, méthode, données, maintenance, coût total, réversibilité, références.
- Les poids se fixent avant de voir les offres ; sinon la grille ne fait que justifier un choix déjà décidé.
- On note les faits écrits dans l'offre, pas la sympathie du commercial ; une info de sécurité manquante est une mauvaise note.
- Comparez le coût total sur 2-3 ans (mise en place + abonnement + support + changements), pas le prix affiché.
- Le CDC énonce, la grille vérifie : chaque exigence forte du CDC doit avoir un écho dans la grille.

**Plan de la leçon :** Le cas d'entreprise : Meubles Rossier SA et son goulot d'étranglement · Étape 1 — Cadrer le problème avant d'écrire une ligne · Étape 2 — Le cahier des charges : périmètre, données, contraintes, livrables · Étape 3 — La trame de cahier des charges réutilisable · Étape 4 — Construire la grille d'évaluation pondérée · Étape 5 — Le scénario de comparaison : deux offres face à la grille · Corrigé commenté : ce qui distingue un bon CDC et une bonne grille · Vos livrables, le portfolio et la préparation à l'attestation

_Contenu complet réservé aux abonnés — [suivre ce cours](https://successfor-me.ch/academy/cours/fiche/IA-18)._