# API ou MCP : lequel choisir pour intégrer des données de mobilité ?

> Comparez API et MCP pour les données de mobilité : application web, automatisation, assistant IA, contrôle des requêtes et exemples avec ROOTE.

Source: https://www.roote.ai/fr/guides/api-ou-mcp-mobilite/
Language: fr
Author: ROOTE

Choisissez une API lorsque votre application doit lancer des requêtes définies par votre code. Choisissez MCP lorsque vous voulez qu’un assistant compatible découvre et utilise des outils dans une conversation. Pour les données de mobilité, les deux approches peuvent coexister dans le même produit.

La décision porte sur la façon d’accéder au service, pas sur une opposition entre données fiables et données approximatives. Une API et un serveur MCP peuvent s’appuyer sur les mêmes sources ; il faut comparer leurs contrats, leurs capacités et leurs limites réelles.

## API : votre code décide des appels

Une API HTTP permet à votre serveur de choisir la route, les paramètres, les moments de recherche et le traitement des réponses. C’est une approche adaptée à une liste d’arrêts, un filtre de carte ou une tâche planifiée dont le comportement doit être prévisible.

Votre application prend en charge la validation, le cache, les délais d’attente, l’affichage des erreurs et les secrets. Une API n’empêche pas de construire un assistant : vous pouvez aussi relier ses routes à des fonctions utilisées par un modèle.

[Exemple de recherche de proximité avec l’API ROOTE](https://www.roote.ai/fr/guides/api-arrets-transport-proximite/)

## MCP : des outils accessibles dans la conversation

Un serveur MCP publie des outils avec leurs schémas d’arguments. L’application IA les découvre et peut les utiliser pour répondre à une demande en langage naturel. Cela facilite une connexion à des clients compatibles sans refaire une intégration propre à chacun.

Le modèle ne reçoit pas le droit d’inventer des paramètres ni d’interpréter une erreur comme un résultat vide. Le client et votre application doivent conserver les contraintes du service. Les capacités découvertes restent la référence.

[Comprendre l’architecture officielle MCP](https://modelcontextprotocol.io/docs/learn/architecture)

## Choisir selon le résultat que vous voulez obtenir

| Projet | Choix de départ | Pourquoi |
| --- | --- | --- |
| Liste d’arrêts sur un site | API | Le code contrôle les filtres, les appels et le rendu |
| Assistant compatible recherchant autour d’une adresse | MCP | Les outils sont accessibles depuis la conversation |
| Export périodique ou traitement métier | API | Le scénario ne dépend pas d’une interprétation conversationnelle |
| Carte sans interface à développer | Embed ROOTE | L’iframe fournit directement une expérience cartographique |
| Produit combinant carte et assistant | API et MCP | Chaque interface répond à une interaction différente |

## Comparer les capacités plutôt que les seules interfaces

Les outils Data du MCP ROOTE couvrent le géocodage, la recherche de proximité et les perturbations avec transit_disruptions. Journey et Departures ne sont pas encore exposés, même si le contrat REST documente des routes correspondantes. transit_nearby découvre les lieux de transport ; il n’annonce pas leurs prochains départs. Comparez les outils réellement annoncés par le serveur.

Les noms de filtres, les types et les plafonds peuvent aussi varier. Par exemple, les modes MCP transit sont une liste de chaînes ; les modes d’une URL de carte sont encodés dans un paramètre. Ne recopiez pas une configuration entre interfaces sans contrôler son schéma.

[Référence officielle API ROOTE](https://api.roote.ai/)

[Référence officielle MCP ROOTE](https://mcp.roote.ai/)

## Évaluer la charge d’intégration

Pour l’API, estimez le travail sur la validation des réponses, la gestion des erreurs et le rendu. Pour MCP, vérifiez la compatibilité du client, la découverte des outils, le comportement de l’assistant et la façon de conserver les avertissements. Une connexion rapide ne remplace pas les tests du parcours.

Dans les deux cas, mesurez les appels réellement effectués et appliquez les limites actives du service. N’annoncez pas un coût fixe par conversation sans avoir observé les recherches, les reprises et les droits du compte.

## Un exemple : un hôtel aide ses visiteurs à se déplacer

Pour afficher une carte de vélos et d’arrêts près de l’hôtel, un embed peut suffire. Pour personnaliser une liste dans son interface, le site peut appeler l’API côté serveur. Pour répondre à « où trouver des toilettes et un tram autour de mon adresse ? », un assistant compatible peut utiliser le MCP.

Ces parcours ne doivent pas se masquer mutuellement : la carte affiche les informations disponibles, la liste expose ses filtres et l’assistant explique ce qu’il a réellement trouvé. Un service inconnu ne devient pas absent parce que son champ manque.

[Connecter votre assistant au MCP ROOTE](https://www.roote.ai/fr/guides/connecter-assistant-mcp-roote/)

[Intégrer une carte dans votre site](https://www.roote.ai/fr/guides/integrer-carte-mobilite-site/)

## À venir : prochains départs et calcul d’itinéraire

ROOTE prévoit d’étendre son MCP aux prochains départs et au calcul d’itinéraire. Ces fonctionnalités sont à venir et ne font pas encore partie des outils actuellement exposés par le serveur MCP. Lors de leur disponibilité, vérifiez les outils annoncés par le serveur, leurs arguments et les informations effectivement retournées avant d’annoncer un passage ou un trajet.

## Questions fréquentes

### MCP remplace-t-il REST ?

Non. MCP peut utiliser une API REST en arrière-plan, et une application peut conserver son intégration REST en parallèle.

### Une automatisation doit-elle passer par MCP ?

Pas nécessairement. Pour une suite d’appels définie et répétable, une API suffit souvent. MCP devient utile si votre environnement d’automatisation l’utilise déjà ou si un assistant choisit les outils.

### Les mêmes fonctionnalités sont-elles disponibles partout ?

Vérifiez l’inventaire de chaque interface. Les capacités REST, MCP et carte ne sont pas automatiquement identiques.