Exemples : GPT Connecté à un CRM, un Calendrier, une Base de Données

Passer de la théorie à la pratique

Vous savez désormais ce qu’est une Action et comment sécuriser son authentification. Il est temps de voir à quoi ressemble un GPT connecté une fois sorti du laboratoire. Cette leçon décortique trois cas concrets — un CRM, un calendrier, une base de données — en détaillant à chaque fois le besoin de départ, la configuration retenue et ce que l’utilisateur obtient au quotidien. Vous verrez qu’au-delà des différences d’outils, les trois montages obéissent aux mêmes principes de conception, que nous dégagerons en fin de leçon.

Cas 1 : interroger son CRM en langage naturel (HubSpot)

Imaginez un directeur commercial qui passe ses journées entre deux rendez-vous. Chaque fois qu’il veut vérifier l’état d’une opportunité, il doit ouvrir HubSpot, naviguer dans les filtres, retrouver la bonne vue. Son besoin est simple : poser ses questions comme il les poserait à un assistant humain, et obtenir la réponse sans quitter sa conversation.

La configuration reste volontairement minimale : le schéma OpenAPI n’expose que trois endpoints — GET /contacts pour rechercher des contacts par nom, entreprise ou statut, GET /deals pour lister les opportunités avec filtres (montant, étape, date), et POST /notes pour ajouter une note à un contact. L’authentification repose sur une clé API HubSpot transmise en Bearer token, avec des permissions limitées à la lecture et à l’ajout de notes. Ce choix n’est pas anodin : même si le GPT était manipulé par un utilisateur malveillant, il ne pourrait ni modifier un deal ni altérer les coordonnées d’un contact, car l’API elle-même le lui interdit. Les instructions du GPT verrouillent une seconde fois le périmètre : elles précisent qu’il est un assistant commercial connecté au CRM HubSpot, qu’il doit utiliser l’API dès qu’on l’interroge sur un contact ou une opportunité, qu’il reformule toute note et demande confirmation avant de l’ajouter, et qu’il ne modifie jamais le statut d’un deal ni les coordonnées d’un contact.

Le résultat, à l’usage, change le quotidien du directeur commercial. Il tape « Quels sont mes deals en négociation de plus de 50 000 euros ? » et obtient une liste formatée. Il demande « Montre-moi les contacts de l’entreprise Durand & Fils » ou dicte « Ajoute une note au contact Marie Leroy : appel du 15 mars, intéressée par l’offre Premium » — le GPT reformule, attend le feu vert, puis écrit dans HubSpot.

Cas 2 : gérer un calendrier par conversation (Google Calendar)

Deuxième situation : une assistante de direction jongle avec l’agenda de son dirigeant, entre créations de réunions, décalages de dernière minute et vérifications de disponibilité. Ici, contrairement au CRM, l’écriture est au cœur du besoin — il faut pouvoir créer, déplacer et annuler des événements. Le schéma OpenAPI couvre donc quatre endpoints : GET /events pour lister les événements d’une période, POST /events pour créer un événement, PUT /events/{id} pour modifier un événement existant et DELETE /events/{id} pour l’annuler.

Parce que le GPT touche à des données Google personnelles, l’authentification passe par OAuth 2.0, avec le scope calendar.events uniquement : le GPT peut lire et écrire des événements, mais pas toucher aux paramètres du calendrier. Plus le pouvoir d’écriture est grand, plus les garde-fous des instructions comptent. Celles-ci imposent au GPT de résumer toute création ou modification et de demander confirmation avant d’agir, exigent une double confirmation avant toute suppression, et lui demandent de vérifier systématiquement les conflits d’horaire avant de proposer un créneau.

Concrètement, l’assistante demande « Qu’est-ce que j’ai demain après-midi ? », « Place une réunion avec l’équipe marketing mardi à 14h pendant 1h » ou « Décale le point avec Pierre de 10h à 11h ». Le GPT vérifie les disponibilités, annonce ce qu’il s’apprête à faire, et n’exécute qu’après validation. La friction ajoutée par la confirmation est le prix — modeste — d’un agenda qui ne se retrouve jamais saccagé par un malentendu.

Cas 3 : explorer une base de feedbacks (Airtable)

Troisième cas : une équipe produit centralise tickets et retours clients dans Airtable, mais tout le monde ne maîtrise pas la syntaxe des filtres. Plutôt que de former chacun à l’outil, l’équipe met la base en conversation. Deux endpoints suffisent : GET /records pour lister les enregistrements avec filtres et tri, et POST /records pour créer un nouvel enregistrement. L’authentification utilise une clé API Airtable en Bearer token, dont l’accès est restreint à la seule base « Feedbacks Produit » — les autres bases de l’espace de travail restent invisibles.

Les instructions donnent au GPT son rôle d’assistant produit connecté à la base de feedbacks, lui demandent d’interroger la base avec les filtres appropriés dès qu’une question porte sur les retours clients, et imposent un format de restitution : un tableau avec les colonnes date, client, catégorie et résumé. Surtout, elles fixent une limite claire : le GPT peut créer de nouveaux tickets, mais jamais modifier ou supprimer les existants. N’importe quel membre de l’équipe peut alors demander « Combien de bugs ont été remontés ce mois-ci ? », « Quels sont les feedbacks les plus récents sur la fonctionnalité de facturation ? » ou dicter « Crée un ticket : bug d’affichage sur la page de paiement, signalé par le client Dupont le 28 mars ».

Ce que ces trois cas ont en commun

En prenant du recul, trois patterns traversent ces montages pourtant différents. Le premier est la règle d’or des GPTs connectés : lecture libre, écriture contrôlée. Les trois GPTs consultent leurs données sans friction, mais aucun n’écrit sans confirmation explicite de l’utilisateur. Le deuxième pattern tient aux instructions : un GPT ne devine pas quand déclencher une Action. Dans les trois cas, les instructions disent explicitement « quand l’utilisateur demande X, utilise l’action Y » — sans cette consigne, le modèle risque de répondre de mémoire au lieu d’interroger la source. Le troisième pattern est la sobriété du périmètre : aucun des trois GPTs n’expose l’intégralité de l’API de son outil. Deux à quatre endpoints, choisis pour le cas d’usage, rien de plus.

Pour transposer la démarche chez vous, suivez l’ordre de construction que ces trois exemples illustrent :

1. Identifiez un outil que vous utilisez quotidiennement, qui dispose d’une API, et définissez deux ou trois cas d’usage concrets — les questions que vous posez le plus souvent
2. Créez un schéma OpenAPI minimal avec les seuls endpoints nécessaires
3. Configurez l’authentification appropriée (clé API ou OAuth)
4. Ajoutez des garde-fous dans les instructions pour toute opération d’écriture
5. Testez avec des requêtes réelles avant d’ouvrir l’accès à d’autres

Un mot sur les pièges observés chez les créateurs débutants. Le plus fréquent consiste à connecter une API « au cas où », sans cas d’usage précis : on obtient un GPT qui sait tout faire en théorie et rien de bien en pratique. Le plus dangereux est d’autoriser l’écriture sans confirmation — un GPT qui crée ou modifie des données sans validation peut causer de vrais dégâts dans un CRM ou un agenda partagé. Pensez aussi aux erreurs d’API : si le service est indisponible ou renvoie une erreur, votre GPT doit savoir quoi dire à l’utilisateur plutôt que d’inventer une réponse. Enfin, résistez à la tentation d’exposer trop d’endpoints : chacun consomme du contexte, et au-delà de cinq, la précision du GPT se dégrade.

Points clés à retenir

• Les GPTs connectés à des outils réels (CRM, calendrier, base de données) résolvent des problèmes concrets du quotidien
• Appliquez la règle d’or « lecture libre, écriture contrôlée » : toujours confirmer avant de modifier
• Mentionnez explicitement les Actions dans les instructions pour que le GPT sache quand les déclencher
• Limitez les endpoints au strict nécessaire (2 à 5) et prévoyez la gestion des erreurs API
• Commencez simple — un outil, deux endpoints — et enrichissez progressivement