Commencez à construire votre équipe personnelle.

Une instruction qui tourne en boucle. Le modèle reçoit du texte (votre objectif, plus une liste d'outils qu'il a le droit d'utiliser), produit du texte (une demande d'utiliser un outil, ou une réponse finale), nous exécutons l'outil, collons le résultat dans le contexte et interrogeons à nouveau le modèle. Il boucle jusqu'à ce que le modèle cesse de demander des outils. L'intelligence n'est que la prédiction du prochain jeton. La boucle est ce qui transforme la prédiction en travail.

Aussi sûr que les outils que vous lui connectez. Le modèle lui-même est texte entrant, texte sortant — il ne peut faire que ce que votre liste d'outils lui permet. Le risque réside en trois endroits : les permissions lecture versus écriture, les données sensibles versus publiques, et ce qui est auto-approuvé versus vérifié par un humain. Nous commençons en lecture seule, brouillons uniquement (pas d'envois), un flux de travail à la fois. Chaque appel au modèle est journalisé pour que vous puissiez voir ce qu'il a demandé, ce qu'il a reçu et ce qu'il a fait.

L'agent lui-même, c'est quelques minutes. Le connecter à votre boîte mail, calendrier, CRM et obtenir les autorisations via l'IT, c'est une heure ou deux. Rédiger l'instruction qui produit un bon résultat de manière fiable, c'est de quelques heures à deux semaines — c'est là que se trouve 80 % du travail. Le premier est lent. Au quatrième, vous clonez des schémas et l'essentiel du temps passe dans la plomberie des données, pas l'agent.

La partie logicielle — oui : lire ce qu'il y a dans le frigo, planifier une semaine de menus, générer la liste, appeler l'API de commande en ligne de votre supermarché. La partie physique — non : il ne peut pas porter les sacs. La limite est là où le numérique s'arrête et où les atomes commencent. Tant que vous ne le connectez pas à un robot avec des mains, il s'arrête à « commande passée ».

Pour l'utiliser, non. Pour bien le configurer, oui — mais « technique » ici signifie penser clairement, pas coder. Les parties difficiles consistent à décider à quoi ressemble un bon résultat, choisir quelles étapes un humain vérifie versus s'exécutent automatiquement, et identifier les cas limites. Nous faisons cela en ateliers avec la personne qui a la tâche ennuyeuse, pas son développeur. Les outils font la frappe.

Il le fera, régulièrement. Les modèles hallucinent — ils affirment avec assurance des choses qui ne sont pas vraies. Les outils renvoient des erreurs que le modèle interprète mal. Les instructions rencontrent des cas que personne n'a anticipés. La défense n'est pas « le rendre parfait » — ce sont des points de contrôle et un rayon d'impact limité. Chaque action est un brouillon (vous vérifiez avant l'envoi), réversible (vous pouvez l'annuler), ou auditée (vous pouvez la retracer plus tard). Configurez cela correctement et l'erreur devient détectée, pas des dégâts causés.