Suivi de projet par IA : moins de rappels répétés, sans manquer les changements

Illustration conceptuelle générée par IA, contenu constituant un exemple hypothétique.

Supposez que vous demandiez à une IA de surveiller un projet dont la livraison est prévue le vendredi. Le lundi, elle vous rappelle que le client n’a pas encore confirmé les documents ; le mardi, elle envoie un résumé presque identique. Le mercredi, le client a déjà proposé un report par e-mail, mais le tableau de bord du projet indique toujours une livraison le vendredi. L’assistant place les deux dates dans son rapport et vous conseille finalement de « continuer à surveiller ».

Vous devez quand même ouvrir vos e-mails, consulter le tableau de bord, puis redemander au responsable.

Un suivi continu doit conserver le jugement précédent et expliquer ce qui a changé cette fois-ci. Si chaque exécution résume à nouveau l’ensemble des documents, l’assistant risque facilement de présenter d’anciens messages comme de nouveaux progrès, ou de traiter une proposition non encore confirmée comme un arrangement déjà en vigueur.

Après un premier résumé, que faut-il encore conserver

Les tentatives pour organiser l’information entre applications sont déjà nombreuses. Le cas du journal familial quotidien de Composio compose un petit journal du jour à partir du calendrier, de la météo et de contenus ludiques ; la présentation de l’AI teammate de Lindy aborde le contexte continu et le suivi proactif. Ces contenus montrent ce que l’information du jour peut devenir une fois organisée, mais ne répondent pas à une question plus précise : entre deux vérifications successives, quels jugements déjà confirmés faut-il conserver.

Un résumé du jour vous aide à comprendre l’organisation immédiate ; une tâche de suivi continu doit en plus expliquer ce qui s’est passé par rapport à la fois précédente.

Prenons l’exemple d’une livraison de projet : après une première organisation des documents, peu de choses méritent d’être conservées : la date de livraison actuellement confirmée, les documents encore attendus, la personne chargée du suivi, et les sources qui étayent ces jugements. Il faut aussi noter jusqu’à quel moment cette vérification a couvert, et quelles sources n’ont pas pu être lues.

Cette trace constitue le point de départ de la vérification suivante. Elle peut être conservée dans une base de données applicative, un enregistrement de tâche ou un document contrôlé ; la forme exacte est décidée par le système de l’assistant. L’important est que les exécutions suivantes puissent réellement la lire, et sachent quels éléments sont confirmés et lesquels ne sont que des suppositions.

Si la fois précédente ne contenait qu’une phrase du type « le projet avance normalement », il sera difficile la fois suivante d’expliquer ce qui a précisément changé.

Un nouveau message ne signifie pas forcément que les choses ont progressé

Le même document a été transféré dans un groupe, une réponse « bien reçu, merci » est arrivée dans la boîte mail, quelqu’un a modifié la description d’une tâche sur le tableau de bord. Ce sont de nouveaux enregistrements, mais leur impact sur la livraison diffère.

On peut comparer autour des faits qui intéressent la tâche. Pour ce projet, ce que vous avez réellement besoin de savoir est : les documents sont-ils complets, la date de livraison a-t-elle changé, qui a pris en charge la tâche en attente, et un nouveau blocage est-il apparu.

Voici un ensemble de situations hypothétiques :

Ce qui a été lu cette fois	Comment l’interpréter	Quel type de rappel convient
Un collègue a transféré la demande de documents de lundi	Même sujet, aucune nouvelle information de livraison	Ne pas renvoyer le même rappel en double ; rappeler tout de même à l’échéance
Le client a envoyé la pièce jointe qui manquait auparavant	Le document a été reçu ; reste à vérifier s’il satisfait aux exigences	Indiquer ce qui a été reçu et ce qui manque encore
Le client demande si la livraison peut être reportée à lundi prochain	Une demande de report est apparue	Marquer comme à décider, conserver la date actuellement confirmée
Le responsable accepte explicitement le report	Un nouvel enregistrement de confirmation apparaît	Indiquer l’ancienne date, la nouvelle date et la source de la confirmation

Pour identifier un même enregistrement, on peut utiliser l’identifiant fourni par le système source ; pour déterminer si des enregistrements différents décrivent la même chose, il faut aussi tenir compte du projet, des participants et du contenu. Un titre identique ne suffit pas à fusionner deux e-mails de manière fiable. Un texte différent ne doit pas non plus faire conclure que le projet a avancé d’un pas de plus.

Les champs déjà explicites se prêtent à une comparaison directe ; les endroits qui demandent une compréhension sémantique sont confiés au modèle. Par exemple, on identifie d’abord les tâches dont le champ de date a changé, puis on demande à l’IA de lire les discussions associées pour expliquer si ce changement a déjà été confirmé.

Quand l’e-mail et le tableau de bord divergent, conserver la divergence

L’e-mail de mercredi propose une livraison le lundi suivant, le tableau de bord indique toujours vendredi. Lequel compte ?

« Mis à jour plus tard » indique seulement l’heure d’enregistrement, pas que l’auteur a le pouvoir de modifier l’organisation. L’e-mail peut être une demande, le tableau de bord peut ne pas encore avoir été mis à jour, ou peut simplement citer la date d’une autre tâche.

L’équipe peut convenir à l’avance de la règle de référence. Par exemple, la date de livraison fait foi après confirmation du responsable désigné, et le tableau de bord sert à enregistrer l’organisation une fois confirmée. Ainsi, lorsque l’assistant voit l’e-mail de report, il peut le classer parmi les éléments à confirmer ; lorsqu’il voit l’accord du responsable, il peut signaler que le tableau de bord doit encore être synchronisé.

En l’absence de règle convenue, l’assistant doit présenter les deux enregistrements ensemble, expliquer la divergence et laisser le responsable décider. Voici un exemple de rappel fictif :

Le client a demandé aujourd’hui par e-mail de reporter la livraison à lundi prochain ; le tableau de bord du projet indique toujours vendredi. Dans les enregistrements actuellement lisibles, aucune confirmation de report du responsable n’a été trouvée. Veuillez confirmer si la demande est acceptée.

Lorsqu’on cite une source, il faut fournir un lien réel et ouvrable ; écrire seulement « e-mail du client » ou « tableau de bord » ne permet pas au responsable de vérifier.

Ici, une décision humaine est nécessaire, et la demande est très claire. Par rapport à « veuillez continuer à surveiller les risques du projet », le responsable sait ce qu’il doit répondre et peut ouvrir directement la source.

Absence de changement, échec de vérification et échéance : à traiter séparément

Un assistant qui fonctionne en continu doit permettre des résultats silencieux. Si les sources désignées ont été vérifiées correctement et que rien n’a changé, il peut enregistrer le résultat de la vérification et, selon ce qui a été convenu, ne plus envoyer de résumé en double.

Mais si la lecture de la boîte mail échoue, on ne peut pas tirer la même conclusion. L’assistant sait seulement qu’il n’a pas pu effectuer la vérification ; il doit conserver la position de la dernière lecture réussie et indiquer les sources manquées cette fois. Après le rétablissement de l’accès, il faut vérifier les enregistrements de la période manquée ; si l’interface fournit un curseur incrémental, on peut reprendre la lecture selon ses conventions, sinon il faut concevoir une requête couvrant la période manquée. On ne peut pas se contenter de vérifier le jour du rétablissement et supposer qu’il n’y a eu aucun changement entre-temps.

L’article de Viktor sur les automatisations qui échouent silencieusement décrit combien il est difficile de remarquer qu’une tâche de longue durée a cessé de fonctionner. Il en va de même pour une tâche de suivi : lorsqu’aucun rappel n’arrive, vous devriez pouvoir vérifier si elle s’est exécutée la dernière fois et quelles sources elle a contrôlées.

Il existe un autre cas où un rappel est nécessaire même sans nouveau message : l’échéance convenue est atteinte. Le client n’a jamais répondu ; au moment du suivi convenu entre les deux parties, ce point mérite de réapparaître.

Ainsi, un rappel peut provenir d’un changement réel ou d’une condition temporelle convenue à l’avance. Après la fin, l’annulation ou la prise en charge de la tâche par le responsable, il faut aussi arrêter les rappels correspondants. Sinon, un travail déjà terminé continuera chaque jour à vous demander de vous en occuper.

OOMOL fournit des connexions applicatives pour les tâches de suivi

Pour comparer les changements entre deux vérifications, l’assistant doit lire les enregistrements dans les systèmes réels. Dans OOMOL, le Connector SDK explique comment choisir un compte de connexion déjà autorisé et appeler l’opération applicative correspondante ; la passerelle se charge de détenir les identifiants et d’émettre la requête réelle.

Par exemple, pour le suivi d’un projet, connectez la boîte mail professionnelle et l’outil de gestion de projet, puis vérifiez s’ils fournissent les champs de recherche, de lecture de détail et de date de mise à jour nécessaires. La portée des requêtes, l’historique et les capacités incrémentales varient selon les services ; il faut les confirmer interface par interface.

L’état confirmé lors de la vérification précédente, les liens entre différentes sources, les conditions de rappel et les conditions d’arrêt sont, eux, conservés et exécutés par l’assistant ou le processus métier. Une fois la connexion réussie, ces règles de tâche doivent encore être mises en œuvre.

La première version peut n’ouvrir que les opérations de lecture nécessaires et confier le rapport de changement au responsable. Lorsqu’il faut synchroniser le tableau de bord ou répondre au client, configurez les opérations correspondantes selon le guide de contrôle des accès, en précisant la cible d’exécution et le mode de confirmation.

Si une équipe doit gérer elle-même le service de connexion, elle peut utiliser le projet open source d’OOMOL OpenConnector et gérer les identifiants, les politiques d’opération et les journaux d’exécution selon le guide d’auto-hébergement.

Vérifier deux fois de suite avec le même projet

Vous pouvez connecter les applications nécessaires à la tâche depuis OOMOL Connections, puis confier à un assistant capable d’appeler les connexions et de conserver l’état des tâches une demande à la portée bien définie :

Aide-moi à suivre la date de livraison et les documents à livrer de ce projet. Lis d’abord la conversation e-mail désignée et les tâches du projet, organise l’état actuellement confirmé, les points à confirmer et les sources, et enregistre-les comme base de comparaison pour la suite. Cette fois, remets-moi seulement le résultat, sans modifier les systèmes sources. Lors de la prochaine vérification, explique ce qui a changé par rapport à cette fois ; s’il n’y a pas de changement, ne répète pas le résumé ; en cas d’échec de lecture, indique ce qui manque. Je confirmerai les horaires de rappel et les conditions d’arrêt avant de les définir.

Lors de la première vérification, contrôlez s’il a bien choisi le projet, les e-mails et le responsable. Pour la deuxième, vous pouvez ajouter avec des documents de test un transfert en double, une demande de report et une confirmation formelle, et observer si l’assistant sait distinguer les trois. Rendez ensuite une source temporairement indisponible et vérifiez s’il présente l’échec de lecture comme une « absence de progrès ».

Une fois que ces jugements correspondent à vos attentes, planifiez l’exécution périodique. Le prochain rappel que vous recevrez devrait alors répondre à une question précise : par rapport au dernier état confirmé, qu’y a-t-il maintenant qui demande votre intervention ?