Comment Scalter choisit la prochaine action utile

Scalter est l’assistant de Scalt. Il cherche dans les sources auxquelles vous avez accès, répond en montrant les documents utilisés, et peut créer un dossier suivi à partir de votre demande. Mais une réponse n’est souvent que le début : la vraie question est « que faire ensuite ? ». Voici comment Scalter propose la prochaine action utile, et les choix que nous avons faits pour qu’elle le reste.

Trop d’outils, pas de fil

Dans une journée de travail, les sujets sont éparpillés : une demande dans le chat, un document dans le drive, une validation qui attend dans un email, un agent qui a échoué pendant la nuit. Chaque outil a ses notifications, et aucune ne dit par quoi commencer. Le coût n’est pas seulement le temps perdu à chercher : c’est aussi ce qui passe entre les mailles, faute d’avoir été vu.

Un assistant qui se contente de répondre ajoute un outil de plus. Nous voulions l’inverse : qu’à partir d’une question, ou simplement du début de la journée, Scalter aide à passer à l’action. Ouvrir le bon dossier, valider ce qui attend, relancer ce qui a échoué.

Ce que Scalter propose

• Le brief du matin : ce qui attend votre validation, ce qui a échoué, ce qui tourne, résumé sur le tableau de bord.
• Depuis une réponse : créer un dossier à partir de la demande, l’assigner et le suivre. Le fil de discussion reste attaché au dossier.
• Depuis la conversation : lancer l’agent adapté à la demande, ou valider une action qui attend, sans changer d’outil.

Chacune de ces propositions reste une proposition. Scalter ne valide rien à votre place : une action soumise à validation s’arrête et attend votre accord, et tout ce qui est fait reste consultable dans l’historique.

La prochaine action commence souvent par une vérification. Chaque réponse de Scalter est accompagnée de ses sources : vous ouvrez le document, la ligne ou le message d’origine avant de décider. Cela vaut aussi pour un fichier Excel ou CSV déposé dans la conversation, que vous interrogez feuille par feuille.

Le travail lourd se fait en amont

Pour proposer au bon moment, Scalter ne peut pas tout relire à chaque question. Le travail coûteux est fait en amont, quand les sources sont synchronisées : indexation des documents, liens du graphe entre entreprises, contacts, documents et dossiers, état des dossiers et des exécutions.

Au moment de la demande, il reste un travail plus léger : retrouver ce qui se rapporte à votre question ou à votre journée, parmi ce que vous avez le droit de voir, puis classer les actions possibles à partir de signaux simples : ce qui attend l’intervention d’un humain, ce qui est en retard, ce qui est lié à ce que vous êtes en train de faire.

Des propositions qui disent pourquoi

Chaque proposition porte ses raisons : ce dossier attend votre validation depuis hier ; cet agent a échoué sur une source qui ne répond plus ; ce contrat est lié au client dont vous parlez. Sans raison, une proposition est une injonction. Avec sa raison, elle se vérifie d’un coup d’œil, et se refuse tout aussi facilement.

C’est aussi ce qui nous a obligés à garder le mécanisme simple. Un classement qu’on ne sait pas expliquer ne peut pas afficher ses raisons. Nous avons préféré des signaux lisibles, comme le statut, l’échéance, le lien avec votre demande ou la validation en attente, à un score opaque qu’il faudrait croire sur parole.

Un lundi matin

Prenons une responsable du support qui ouvre Scalt un lundi matin. Le brief lui montre trois choses : deux réponses préparées par l’agent de support attendent sa validation, l’agent de synthèse des tickets a échoué pendant le week-end parce qu’une source ne répondait plus, et un dossier ouvert vendredi par un collègue la mentionne. Pour chaque ligne, la raison est écrite, et l’action est à un clic : relire et valider, relancer après vérification de la source, ouvrir le dossier.

Elle pose ensuite une question sur un client qui a relancé plusieurs fois. Scalter répond avec les tickets et les échanges concernés, puis propose de créer un dossier pour suivre le sujet et de l’assigner à la bonne personne. Elle accepte ; la conversation reste attachée au dossier, et personne n’aura à la chercher demain.

Toujours dans vos droits

Scalter agit en votre nom : il ne lit que ce que vous pouvez lire, dans chaque outil connecté. Une proposition ne peut donc pas révéler l’existence d’un dossier que vous ne voyez pas. Pour la conception, c’est une contrainte forte : les droits sont appliqués au moment de la recherche, pas filtrés après coup sur un résultat déjà calculé. C’est plus exigeant à construire, et c’est ce qui permet de proposer sans rien dévoiler.

Ce que nous avons écarté

• Les actions automatiques « parce que c’est probable » : une proposition reste une proposition, et c’est vous qui décidez.
• Une source de notifications de plus : le brief rassemble ce qui était éparpillé, il ne s’ajoute pas aux alertes existantes.
• Les scores sans explication : une proposition doit pouvoir dire pourquoi elle est là.

Ces choix rendent parfois Scalter moins spectaculaire en démonstration. Ils le rendent surtout prévisible, et un assistant prévisible est un assistant qu’on utilise tous les jours.