Le scheduling AI-first, c'est en fait du scheduling API-first

Chaque outil de scheduling sur le marché est en train de sortir une fonctionnalité IA. La plupart sont la même : une zone de chat dans le coin qui te laisse taper « réserve-moi avec Anna jeudi » et qui fait remplir un formulaire par le modèle.

C'est bien. C'est aussi inintéressant.

La raison, c'est que la valeur n'est pas dans la zone de chat. Elle est dans tout ce que l'assistant peut atteindre. Si l'assistant ne peut atteindre que ce que le design d'un produit a câblé dans sa barre latérale, tu as remplacé un formulaire par un formulaire un peu plus aimable. L'assistant que tu utilises vraiment — Claude, ChatGPT, Cursor, quoi que vienne ensuite — ne vit pas dans ce produit. Il vit ailleurs, et il est meilleur.

Deux modèles de « AI scheduling »

Appelle-les embedded et agent-addressable.

Embedded AI est ce que la plupart de la catégorie fait. Le vendeur héberge un modèle, l'entraîne sur le vocabulaire interne de l'app et l'expose dans un panneau. Le modèle ne peut faire que ce que le vendeur a exposé. Si tu veux qu'il parle aussi à ton CRM, à tes notes, à ton repo, à la booking page d'une collègue — eh bien non. C'est un autre produit.

Agent-addressable est l'inverse. Le vendeur ne livre pas d'IA. Le vendeur livre une surface propre et documentée — une API REST, un serveur MCP, des webhooks — et laisse l'agent auquel l'utilisateur fait déjà confiance opérer dessus. Le modèle n'est pas une fonctionnalité de l'app. L'app est une fonctionnalité du monde du modèle.

Le second gagne pour toute personne qui a déjà un assistant préféré. Et le recoupement entre « personne qui utiliserait de l'AI scheduling » et « personne avec un assistant préféré » est grand et grandit.

Le test

Un bon test pour savoir si un outil de scheduling est vraiment AI-first : est-ce qu'un agent peut faire quelque chose d'utile avec, depuis l'extérieur de l'app ?

Pour un produit embedded-AI, la réponse est presque toujours non. Tu peux utiliser le panneau de chat qu'ils ont construit. Tu ne peux pas faire lire tes bookings dans un rapport hebdo par ton propre agent, les corréler à ton CRM, vérifier les conflits avant un bloc de focus proposé, ni te faire réserver via un workflow que tu as écrit. L'assistant du vendeur est le seul assistant.

Pour un produit agent-addressable, la réponse est oui. S'il y a une API avec assez de surface pour représenter l'intention réelle de l'utilisateur — « qu'est-ce qu'il y a dans mon calendrier », « est-ce que ça entre en conflit », « crée ça » — n'importe quel agent peut la piloter. Aujourd'hui ça veut dire Claude, ChatGPT, Cursor. Demain, ça voudra dire ce que les gens auront adopté ensuite. L'outil n'a pas besoin de deviner.

Ce que ça veut dire pour WhenToMeet

On n'a pas de panneau de chat dans WhenToMeet et on ne prévoit pas d'en construire un. Ça marcherait ; ça ferait bien en démo ; ça rendrait plus facile la diapo de la prochaine levée. Mais ce serait la version la moins intéressante.

Au lieu de ça, on livre une API REST sur /api/v1/ et un serveur MCP sur /api/mcp. Les deux utilisent les mêmes clés. Les deux couvrent la surface dont un assistant a vraiment besoin : lister des events, en lire un, en créer un, lister les bookings, tirer le flux calendrier unifié, vérifier les conflits, lire son propre profil.

Un agent avec ces sept capacités peut faire la plupart de ce qu'on a jamais demandé à un « assistant de scheduling ». Et il peut le faire à l'intérieur de la conversation que la personne a déjà, avec le contexte que cette conversation a déjà.

Ce que la catégorie continue de rater

Deux choses.

Premier, la plupart des fonctionnalités « AI scheduling » optimisent pour la démo de nouveauté — « regarde le modèle réserver une réunion depuis un email ! » — au lieu de la fiabilité ennuyeuse dont une personne a vraiment besoin. Si l'agent crée parfois l'événement au mauvais jour, tu arrêtes de lui faire confiance, et la fonctionnalité est morte. La fiabilité ennuyeuse vient de tools étroits et bien définis, pas d'espérer que le modèle devine bien.

Deuxième, l'industrie continue à construire des assistants qui vivent dans une app. L'assistant de l'utilisatrice vit à travers les apps. Ce sont deux choses différentes, et la seconde est ce que les gens veulent.

Où on va

Version courte de la roadmap : étendre ce que couvrent l'API et les tools MCP, ne pas ajouter de panneau IA. Combler les trous où l'agent peut lire mais pas écrire, lire mais pas éditer. Rendre la surface assez complète pour que personne n'ait à ouvrir notre app pour faire du travail de scheduling, sauf s'il le veut.

Si tu veux l'essayer aujourd'hui, récupère une clé API, pointe ton client MCP sur l'endpoint et demande-lui de regarder ton calendrier. Setup sur docs.whentomeet.io.

L'IA intéressante n'est pas celle qu'on construirait. C'est celle que tu utilises déjà, pointée sur une surface propre. C'est la seule version d'« AI-first » qui mérite d'être livrée.