IA : de l'idée
à l'agent.

Mustapha ouvre la session avec une intention simple : prendre le temps de comprendre ce que chacun fait déjà avec l’IA, ce qui fonctionne, et ce qui résiste encore. L’atelier doit rester pratique et ouvert aux questions. Son constat est que le sujet produit beaucoup de bruit, alors que les personnes ont surtout besoin de repères communs et de méthodes applicables à leur travail.

Le tour de table fait apparaître des besoins différents, mais une même impression : « Je l’utilise, mais je pourrais mieux l’utiliser. »

• Une participante en recherche d’emploi adapte son CV et ses lettres avec un assistant IA. Elle constate parfois que l’outil invente des missions qu’elle n’a jamais effectuées. Elle voudrait mieux répondre aux offres et décrocher des entretiens.
• Une responsable des relations avec des écoles utilise surtout l’IA pour reformuler. Elle aimerait préparer plus rapidement des réponses aux e-mails, sans envoyer des messages impersonnels.
• Un participant en reconversion utilise plusieurs assistants, mais ne sait pas s’il en tire le meilleur parti.
• Une développeuse IA conçoit des automatisations pour ses clients ; elle aimerait aussi en mettre en place pour mieux gérer ses propres messages.
• Un responsable RH explique comment il utilise l’IA pour analyser des données, préparer des présentations et automatiser une enquête d’opinion interne.

Mustapha invite le groupe à ne pas commencer par l’outil. Il propose d’abord de regarder la tâche, sa fréquence et le degré d’autonomie nécessaire. Une demande ponctuelle peut se traiter avec un bon prompt. Une tâche individuelle répétée peut justifier une skill — des instructions conservées pour être réutilisées. Un agent prend davantage de sens pour une tâche durable, notamment lorsqu’elle implique plusieurs étapes ou un usage partagé.

Il reconnaît le plaisir de créer un agent, mais pose une question plus exigeante : est-il encore utilisé un mois plus tard ? L’intérêt n’est pas le nombre d’agents créés ; c’est le travail utile qu’ils continuent de faire.

Mustapha présente trois piliers : les données, les instructions et la sécurité. Le premier est, selon lui, le plus important et le plus souvent négligé. Un fichier clairement nommé, des versions cohérentes et quelques bons exemples peuvent aider davantage qu’un prompt très élaboré appliqué à des documents contradictoires. Il résume l’idée ainsi : « montrer vaut mieux qu’expliquer ».

La développeuse apporte une précision technique : dans un agent construit sur mesure, il ne suffit pas que les bonnes informations existent. Il faut encore que le système sache les extraire correctement d’un PDF, d’un tableau ou d’une base de données. Mustapha ramène ce point au quotidien des utilisateurs : fournir moins de documents, mais des documents plus clairs et plus réguliers, peut simplifier considérablement la tâche de l’IA.

Le responsable RH raconte comment son enquête d’opinion interne a évolué. Au départ, il demandait à l’IA de mettre les résultats en forme ; le rendu ne lui convenait pas. Lorsqu’il a précisé « il s’agit d’un sondage », la restitution a changé. Il décrit aujourd’hui un processus qui rappelle la date de lancement, lui fait valider les questions, prépare les messages, suit la participation et met les résultats en forme.

Mustapha souligne ce qui rend l’exemple intéressant : on n’est plus seulement dans une conversation avec un assistant, mais dans un enchaînement de tâches et de données. Il recommande néanmoins de garder les résultats auditables : demander quelles données et quelles sources ont servi à produire une analyse, puis les vérifier. Il évoque un cas où des rapports sur des questions réglementaires s’appuyaient sur des blogs, sans que cela soit apparent dans le résultat final.

Une participante demande, en substance, si une IA peut chercher à atteindre l’objectif qu’on lui donne par des moyens qu’on n’avait pas prévus. Mustapha répond que c’est précisément une raison de bien définir la logique métier, les limites et les contrôles. Quelques essais réussis ne prouvent pas qu’une tâche fonctionnera correctement à chaque fois.

Il élargit ensuite la discussion à ce qu’il appelle la dette métacognitive. Si l’on délègue systématiquement l’effort de chercher, de rédiger ou de vérifier, on risque de moins exercer ces capacités. Il distingue le fait de ne jamais acquérir une compétence (never-skilling) de celui de perdre une compétence déjà acquise (deskilling). Son propos n’est pas de renoncer à l’automatisation, mais de choisir consciemment ce que l’on délègue et ce que l’on continue à contrôler.

Pour aider chacun à formuler ses demandes, Mustapha présente SCOPE© : Spécialiste, Contexte, Objectif, Public, Exécution. Il s’attarde sur l’objectif : demander « rédige cet e-mail » ne dit pas encore si l’on veut apaiser une tension, obtenir une réponse ou préparer une décision. Dans l’exécution, il conseille de préciser le format attendu et, lorsque l’enjeu le demande, d’exiger les sources permettant de vérifier le résultat.

La démonstration finale rend la méthode tangible. À partir de quelques captures d’écran d’un site, Mustapha demande à l’IA de décrire son design system — couleurs, typographies, espacements et ton. Cette description peut ensuite servir à créer des présentations ou d’autres supports cohérents avec la même identité visuelle, sans repartir de zéro à chaque fois.

Le fil rouge de la session : trouver un usage qui compte vraiment, lui donner des données propres et des consignes claires, puis conserver assez de visibilité pour pouvoir faire confiance au résultat — sans cesser de le vérifier.