Un assistant attend que vous lui parliez. Un coéquipier fait avancer du travail que vous ne surveillez pas. Cette seule différence explique l'essentiel de la confusion qui entoure aujourd'hui l'IA au travail, et elle détermine quelles parties de votre processus doivent évoluer.
Les deux approches sont utiles, et aucune n'est une étape que l'autre franchit naturellement. Ce qui change, c'est l'endroit où vit le travail, qui en est responsable, et comment les autres apprennent ce qui s'est passé. Ce guide trace la frontière entre un assistant IA et un coéquipier IA, énumère les cinq choses qui changent réellement dans la semaine d'une équipe, et dit sans détour à partir de quel moment la métaphore du coéquipier n'aide plus. Sharkly existe à cause de la seconde approche : les frontières ci-dessous sont donc énoncées clairement, sans argumentaire de vente.
TL;DR
Un assistant IA travaille à l'intérieur de votre session : vous écrivez un prompt, il répond, la valeur tient à votre contexte et disparaît dès que vous fermez la fenêtre. Un coéquipier IA se voit confier une unité de travail avec un résultat attendu explicite, l'exécute dans un endroit visible par l'équipe et rend compte dans un enregistrement qui survit à la session. Passer de l'un à l'autre n'exige pas de meilleurs modèles. Cela exige une attribution, une trace d'exécution visible, un état de relecture et une personne qui accepte le résultat.
Les définitions à retenir
Un assistant IA se limite à un prompt. Vous êtes présent du début à la fin. Le résultat produit est une suggestion que vous acceptez ou rejetez, et la question de la responsabilité ne se pose jamais puisque vous n'êtes jamais parti. L'autocomplétion, le chat et la refactorisation en ligne en font tous partie.
Un agent IA qui travaille comme un coéquipier est délimité par une tâche. Il reçoit un objectif, des contraintes et suffisamment de contexte pour avancer. Il se documente, exécute, teste et rend compte. Vous n'êtes pas là au milieu. Cette absence est tout l'intérêt de la démarche, et c'est aussi ce qui engendre toutes les nouvelles exigences ci-dessous. Notre article de définition sur le agentic coding parcourt la même échelle sous un autre angle.
La question qui départage n'est pas l'intelligence. La voici : si vous fermez votre ordinateur portable, le travail continue-t-il, et un collègue peut-il savoir ce qui s'est passé ?
Ce qui change vraiment au travail
1. Le travail devient un élément à part entière, pas un message. Avec un assistant, la demande est un simple tour de conversation. Avec un coéquipier, la demande doit pouvoir être comprise par quelqu'un qui n'était pas là : un résultat attendu explicite, ce qui entre ou non dans le périmètre, les fichiers concernés, les contraintes et la façon dont l'achèvement sera vérifié. Les équipes qui sautent cette étape rédigent des tâches vagues, puis s'en prennent au modèle.
2. L'attribution se dédouble. Une personne reste responsable du résultat. Un agent exécute. Les outils qui fusionnent les deux dans un seul champ « assigné à » produisent des tableaux où plus personne ne peut être interrogé sur quoi que ce soit. Sharkly conserve les personnes assignées et l'exécutant comme deux champs distincts sur une même tâche, ce qui enregistre les deux informations d'un coup.
3. La visibilité cesse d'être optionnelle. Le travail d'un assistant est visible parce que vous l'avez regardé faire. Le travail d'un coéquipier n'est visible que si la plateforme diffuse en continu la progression, les commentaires, les blocages et une trace reliée à un enregistrement partagé. Sinon, le statut honnête de la moitié de votre travail est « demande à Priya, c'est elle qui a commencé ».
4. La relecture devient un état nommé. Pas un « quelqu'un finira bien par y jeter un œil », mais un signal explicite d'attente de relecture humaine qui aboutit dans une file d'attente. Dans Sharkly, ce signal arrive dans la boîte de réception des agents de la personne responsable, aux côtés des échecs et des questions directes.
5. La compétence se partage, ou bien elle reste personnelle. L'art du prompt d'un développeur n'est qu'une astuce d'assistant. Enregistré sous forme de configuration d'agent avec ses instructions, son environnement d'exécution, ses dépôts et des compétences réutilisables, il devient un héritage pour la personne suivante au lieu d'une redécouverte.
| Dimension | Assistant IA | Coéquipier IA |
|---|---|---|
| Unité de travail | Un prompt | Une tâche avec des critères d'acceptation |
| Votre présence | Toujours | Pour orienter et relire |
| Où aboutit le résultat | Votre éditeur ou le chat | Un enregistrement partagé avec une trace |
| Responsabilité | La vôtre, implicitement | Une personne nommée, explicitement |
| Mode de défaillance | Une mauvaise suggestion, écartée | Du travail silencieux que personne ne relit |
| Réutilisation | Une habitude personnelle | Une configuration et des compétences enregistrées |
Une semaine qui change de visage
Ces changements se voient dans l'agenda avant de se voir dans les indicateurs.
Le point quotidien cesse d'être une diffusion de statuts, puisque le tableau les porte déjà. Ce qui mérite cinq minutes, c'est la liste des exceptions : quelles exécutions ont échoué, quels résultats attendent un humain, quelle tâche était rédigée assez mal pour que l'agent se mette à deviner. Cette liste est courte et exploitable, ce que bien peu de points quotidiens parviennent à être.
La planification change aussi de forme. Quand une tâche doit être assez précise pour qu'un agent puisse l'exécuter, le raffinement intervient plus tôt et devient plus concret : les critères d'acceptation ne sont plus une formalité, car un critère vague produit une exécution qu'il faut jeter. Les équipes le remarquent généralement ainsi : on rédige davantage de périmètre en amont et on perd moins de temps en cours de sprint.
La relecture devient la ressource limitante. Trois agents peuvent produire plus de changements en une matinée qu'un relecteur n'en traite en une journée : la véritable contrainte passe donc de la vitesse de frappe à la capacité de lecture. Anticipez-le au lieu de le découvrir : plafonnez la quantité de travail d'agents en cours par relecteur, et considérez une file grandissante de résultats non relus comme le même problème qu'une pile grandissante de pull requests non fusionnées.
Là où la métaphore du coéquipier atteint ses limites
Prenez la métaphore au sérieux et elle commence à induire les gens en erreur de trois façons.
Un agent ne peut pas porter la responsabilité. On peut lui attribuer du travail ; il ne peut pas répondre d'un résultat, être appelé à justifier un compromis le trimestre suivant, ni assumer les conséquences d'une mauvaise décision. Toutes les plateformes sérieuses du secteur l'inscrivent dans leur fonctionnement : Linear garde l'humain comme responsable principal et l'agent comme contributeur, et la façon dont Sharkly présente les choses est la suivante : les agents se documentent, exécutent, testent et rendent compte, tandis que les personnes donnent la direction, accordent l'autorité et acceptent le résultat.
Un agent n'a pas de mémoire continue de votre équipe, sauf si vous lui en fournissez une. Un nouveau collègue s'imprègne du contexte par simple présence. Un agent ne reçoit que ce que vous avez écrit noir sur blanc, et c'est pourquoi un périmètre écrit l'emporte toujours sur un périmètre implicite.
Et l'état d'un agent n'est pas l'état d'un projet. Une tâche peut rester « En cours » pendant que l'agent travaille, attend une réponse, attend une relecture ou signale une erreur. Confondre l'état d'une exécution avec l'état du projet, voilà comment des équipes se retrouvent surprises à la fin d'un sprint. Notre guide sur la gestion de projet avec des agents IA détaille cette séparation.
Ce qu'il faut ajouter avant que les agents se comportent comme des coéquipiers
Quatre éléments, dans cet ordre. Aucun ne nécessite de migration.
- Une tâche dont le résultat peut être relu. Si vous ne pouvez pas dire comment vous vérifieriez le travail, un agent ne le peut pas non plus.
- Un exécutant distinct du responsable. Assignez la personne et l'agent sur le même élément.
- Une exécution visible. Progression, commentaires et trace rattachés à la tâche, lisibles par n'importe qui dans l'équipe.
- Une étape d'acceptation. Une personne nommée passe le travail en terminé après avoir lu les preuves, et non après avoir vu que l'exécution était finie.
Commencez par les appliquer à un seul type de travail récurrent : les mises à jour de dépendances, la couverture de tests sur un module stable, l'échafaudage de migration. Étendez ensuite dès qu'une deuxième personne a relu le résultat d'un agent appartenant à quelqu'un d'autre sans avoir besoin d'un point oral. Téléchargez Sharkly si vous voulez cette boucle déjà configurée, ou construisez-la dans l'outil de suivi que vous utilisez déjà.
FAQ
Un agent IA n'est-il qu'un assistant avec plus de permissions ? Les permissions comptent, mais la vraie différence réside dans l'unité de travail. Un assistant traite un prompt à l'intérieur de votre session ; un agent traite une tâche qui lui survit et rend compte dans un enregistrement partagé.
Faut-il remplacer les assistants par des agents ? Non. Les assistants restent plus adaptés à tout ce que vous voulez piloter frappe par frappe. Les agents sont faits pour le travail que vous pouvez spécifier, déléguer et relire.
Qui relit le travail des agents à grande échelle ? Les mêmes personnes qui relisent les pull requests humaines, et c'est pourquoi la capacité de relecture devient le véritable goulot d'étranglement. Commencez par mesurer combien de temps les résultats attendent avant qu'un humain les ouvre.
Les agents ont-ils besoin de leurs propres comptes et permissions ? Ils ont besoin d'un accès délimité, aussi restreint que le travail l'exige. En pratique, cela signifie des dépôts précis, des machines précises et un modèle de rôles qui détermine qui peut déclencher quel agent. Notre présentation des agents Sharkly en montre une mise en œuvre.
