N'écrivez plus le prompt parfait : montrez à Loom ce qui doit changer

Le problème saute aux yeux. Dans la maquette, le bouton se trouve sous le formulaire ; dans l'application, il est à côté, et le message d'erreur repousse les deux hors de l'écran d'un téléphone. Expliquer cela assez clairement à un agent de programmation IA peut prendre plus de temps que de le montrer à quelqu'un.

Le 22 octobre 2026, Atlassian a présenté plusieurs nouveautés de Loom, dont Record for agent, un mode d'enregistrement qui transforme une démonstration commentée à l'écran en instructions pour un agent IA. Loom, l'outil de vidéo asynchrone utilisé pour montrer son travail à ses collègues, étend cette habitude aux logiciels capables d'exécuter la tâche suivante. Sa documentation décrit une bêta ouverte pour les offres Business + AI et Enterprise, avec une limite de cinq minutes par enregistrement. Annonce ; conditions actuelles.

La nouveauté intéressante n'est pas qu'un agent puisse recevoir une vidéo. C'est qu'un parcours d'enregistrement familier produise désormais un brief que l'on peut examiner, modifier et transmettre à un agent. La qualité de cette transmission devient ainsi une question pratique, plutôt qu'un concours du prompt le plus long.

Logo officiel de Loom, utilisé pour identifier le produit. Il s'agit d'une marque graphique, pas d'une capture de Record for agent. Logo : Loom / Atlassian ; politique d'utilisation des marques.

Un enregistrement transporte ce que la description oublie

Un signalement de bug utile ne se résume pas à « le formulaire ne fonctionne pas ». Il faut connaître l'état initial, l'action qui provoque le problème, le résultat attendu et celui qui est réellement apparu. Lorsque ces détails sont éparpillés entre captures, URL copiées et messages, quelqu'un doit reconstituer leurs liens avant de pouvoir corriger quoi que ce soit.

Le parcours documenté par Loom associe instructions orales, images clés de l'écran, événements d'interaction et liens visités. Dans l'extension Chrome, il peut aussi recueillir des messages de console et des métadonnées de requêtes ou de réponses réseau. La version de bureau propose des outils de sélection et de dessin pour attirer l'attention sur la partie pertinente de l'écran. Ces éléments alimentent le brief généré ; ils ne prouvent pas qu'une correction proposée fonctionnera. Détails de la capture.

À notre avis, cela change l'unité de communication la plus utile. Une capture montre un état ; une phrase décrit une intention ; une courte démonstration peut expliquer comment passer d'un état à un autre. Le brief généré relie cette explication à une tâche exécutable.

On peut voir l'enregistrement comme un colis de contexte. Il doit contenir tout ce qui est nécessaire au changement demandé, et peu d'autre chose. La limite de cinq minutes peut encourager cette discipline : montrer un problème, expliquer sa conséquence et tracer une ligne d'arrivée claire.

Explication originale de la transmission. Vérifier le brief est une étape distincte de l'exécution du travail par l'agent.

Le retour de design devient plus clair quand le comportement attendu se voit

Prenons une équipe qui ajuste une page de paiement. Dans une démonstration illustrative, la personne chargée du design pourrait ouvrir la maquette validée, montrer l'application actuelle et signaler trois différences : l'option de livraison disparaît sur un écran étroit, le total se met à jour trop tard et le message de confirmation met l'accent au mauvais endroit. La valeur vient de la relation entre les deux écrans, pas seulement de leur aspect.

La personne qui relit le prompt généré doit traduire chaque observation en comportement. « Déplace ceci » devient ambigu dès que l'agent ne regarde plus le même instant. « Garder le total de la commande visible après un changement de livraison sur écran étroit » donne à la personne qui réalise la modification un résultat vérifiable.

C'est particulièrement utile lorsqu'un changement implique à la fois un fichier de design et une page en fonctionnement. L'exemple de la documentation Loom décrit justement le passage de Figma à un site web pour expliquer une modification d'interface. La fonctionnalité aide à capturer la référence visuelle, mais il revient à l'équipe de décider quelle référence fait autorité. Une maquette soignée peut encore omettre les états de chargement, d'erreur et d'autorisation. Parcours pris en charge.

Ajoutez donc une phrase indiquant ce qui doit rester vrai. Pour la page de paiement, le total doit par exemple correspondre au mode de livraison sélectionné, ou le focus clavier doit rester sur le champ modifié. Souvent absentes des maquettes visuelles, ces contraintes comptent davantage que la position d'une bordure.

La même approche convient aux textes d'interface. Montrez la phrase dans son contexte réel, expliquez qui la lit et précisez la décision qu'elle doit faciliter. L'enregistrement d'un parcours d'accueil peut révéler une transition confuse qu'un extrait de texte isolé masquerait.

Un signalement de bug demande un début reproductible et une fin observable

Autre scénario utile : un problème récurrent remonté au support. Imaginons qu'un client puisse importer un document sur ordinateur mais ne voie qu'un indicateur de progression vide sur petit écran. Une courte vidéo pourrait montrer le type de fichier, l'action choisie, la transition et l'instant où le retour visuel disparaît.

La tâche générée a toujours besoin d'un critère de fin. « Réparer l'importation » ne dit pas à l'agent s'il s'agit d'un fichier rejeté, d'une réponse réseau manquante ou d'une interface qui n'affiche pas un résultat pourtant réussi. Un brief plus utile sépare le symptôme observé de la cause supposée.

Nous limiterions la première mission : reproduire l'absence de retour, identifier la couche responsable et proposer une modification accompagnée d'un contrôle de non-régression. Si l'agent découvre ensuite une erreur serveur, cette preuve peut élargir l'enquête. Elle ne doit pas transformer silencieusement une plainte de mise en page en refonte générale du système d'importation.

L'avantage est concret pour les personnes peu à l'aise avec les journaux techniques. Elles peuvent montrer la séquence défaillante sans devoir d'abord poser un diagnostic. L'ingénieur ou l'agent utilise le contexte capturé pour chercher la cause, tandis que l'observation d'origine reste disponible pour comparer après correction.

Cela ne fait pas de l'enregistrement un substitut à un cas de test. Les deux ont des rôles différents. La vidéo préserve ce qu'une personne a rencontré ; le test décrit le comportement que le logiciel doit continuer de respecter. Un parcours réussi transforme la première en une version appropriée du second.

Copier un prompt et créer une tâche Jira sont deux points d'entrée distincts

La bêta ouverte de Loom est accessible depuis l'extension Chrome ou l'application de bureau en version 2.0 ou ultérieure. La documentation distingue aussi le parcours simple par prompt de la création d'un élément de travail Jira, qui exige un compte géré par Atlassian et un abonnement Jira actif. Cette différence compte pour une petite équipe souhaitant essayer la transmission sans réorganiser sa gestion de projet. Disponibilité et configuration.

L'essai le plus simple consiste à choisir une tâche unique, à faible impact, dans un projet déjà connu :

1. Ouvrez le design pertinent, une page de test publique ou un environnement de développement, puis préparez un état initial facile à expliquer.
2. Sélectionnez Record for agent dans un outil Loom compatible et décrivez un seul changement en montrant les interactions concernées.
3. Arrêtez avant la limite de cinq minutes et lisez le plan d'action généré du début à la fin.
4. Corrigez les références ambiguës, retirez les éléments sans rapport et ajoutez un critère d'acceptation concret.
5. Copiez le prompt au format Markdown dans l'agent de votre choix, ou utilisez le transfert ou le parcours Jira pris en charge pour votre compte.
6. Vérifiez le résultat de l'agent par rapport au scénario d'origine avant d'accepter sa modification.

Cette séquence rend le premier essai compréhensible. Elle permet aussi de juger simplement l'utilité de la fonctionnalité : comparer le temps nécessaire pour préparer une mission claire et le nombre de demandes de précision qu'elle provoque.

Qu'un agent termine vite ne suffit pas. Si un collègue ne peut pas expliquer ce qui a changé ni pourquoi cela répond à l'observation initiale, la transmission reste à améliorer. Le gain le plus utile est de réduire la reconstitution du contexte, plutôt que la vérification.

Un contexte plus riche demande aussi de choisir plus délibérément ce que l'on partage

Le contexte technique supplémentaire est précieux, car l'écran seul n'explique pas toujours ce qui s'est passé. Une requête en échec, une redirection inattendue ou une erreur de console peuvent indiquer une autre cause que celle suggérée par le symptôme visible. Ces mêmes détails peuvent contenir des informations que l'on ne souhaite pas envoyer vers un autre outil.

Avant d'enregistrer, utilisez une page de test pertinente et gardez le périmètre de la tâche visible. Après l'enregistrement, recherchez dans le brief les URL propres au compte, les identifiants de clients et le contenu de journaux inutile. La liste des données capturées dans la documentation justifie un contrôle concret, plutôt que de traiter la vidéo comme une simple image jointe.

L'objectif est de préserver l'information nécessaire pour résoudre le problème. Si un identifiant de requête aide un collègue à retrouver une trace serveur autorisée, il peut être utile. Une longue liste d'URL sans rapport ou une notification personnelle apparue pendant l'enregistrement apporte peu à une tâche d'interface.

Ce sont des questions de relecture éditoriale, pas des autorisations supplémentaires du produit ni une promesse que chaque détail capturé figurera dans chaque tâche générée. Elles aident une équipe à décider ce qui doit entrer dans la mission effectivement envoyée.

Une relecture utile vérifie ce que l'agent peut modifier, les informations qu'il reçoit et la manière dont son résultat sera jugé.

La première mesure utile est la quantité d'explication qui survit

Cette fonctionnalité peut économiser du travail d'au moins trois manières. Une personne chargée du design peut communiquer un écart visuel sans rédiger une description complexe. Un spécialiste du support peut préserver une séquence encore fraîche. Un développeur peut confier à un agent une tâche avec une référence plus claire et un résultat attendu plus précis.

Chaque usage a son propre mode d'échec. Un retour de design peut omettre les comportements hors du parcours nominal. Une démonstration de support peut dépendre d'un état de compte que personne d'autre ne sait reproduire. L'enregistrement d'un développeur peut contenir tant de détails que la demande réelle devient difficile à identifier.

Pour une première évaluation, choisissez plusieurs tâches familières et conservez le même agent et le même dépôt. Notez les retouches nécessaires au brief généré, la fréquence des demandes de précision et le respect du critère annoncé par la modification finale. Ces mesures renseignent mieux la qualité de communication qu'une démonstration isolée de curseur en mouvement.

Il faut aussi distinguer la qualité du résultat de la difficulté de la tâche. Une simple correction de texte peut réussir avec presque n'importe quel brief. Un essai plus révélateur porte sur une petite tâche où le contexte compte : un état de chargement, une mise en page étroite ou une transition entre deux outils. La mission doit néanmoins rester réversible et facile à vérifier par son responsable.

Loom est bien placé pour rendre cette habitude familière, puisque les enregistrements servent déjà à expliquer le travail entre personnes. L'occasion consiste à porter cette clarté dans un parcours avec agent. Le risque consiste à croire qu'une entrée plus riche dispense de préciser ce que l'agent doit accomplir.

Le meilleur brief reste compréhensible par une autre personne

Record for agent fait un pari raisonnable : montrer peut être un point de départ plus efficace que décrire chaque pixel. Son meilleur résultat serait une tâche plus facile à comprendre, pour l'agent comme pour un collègue, avec un lien visible entre l'observation initiale et le changement accepté.

Avant d'envoyer le prochain enregistrement, posez une question : une personne qui ne vous a pas regardé le réaliser pourrait-elle encore expliquer à quoi ressemble la réussite ? Si oui, vous disposez d'un brief utile. Sinon, la prochaine amélioration doit porter sur les instructions avant de porter sur le code.

Sources

• Atlassian : Showing what you mean in the age of AI, 22 octobre 2026.
• Loom : Record for AI agents, documentation de disponibilité, de capture et de parcours consultée le 26 octobre 2026.

Garder la source et les notes vérifiées au même endroit

Pour vos propres enregistrements autorisés, Telli.sh offre un espace distinct où conserver les sources à côté des notes relues. Commencer par une note audio.