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

Passer de la théorie à la pratique

Vous connaissez maintenant les Actions et l’authentification. Cette leçon illustre trois cas concrets de GPTs connectés à des outils professionnels, avec le détail de la configuration et les résultats obtenus.

Cas 1 : GPT connecté à un CRM (HubSpot)

Le besoin

Un directeur commercial veut interroger son CRM en langage naturel au lieu de naviguer dans l’interface HubSpot.

La configuration

Schéma OpenAPI : 3 endpoints exposés

• GET /contacts : rechercher des contacts par nom, entreprise ou statut
• GET /deals : lister les opportunités avec filtres (montant, étape, date)
• POST /notes : ajouter une note à un contact

Authentification : clé API HubSpot (Bearer token), permissions lecture + notes uniquement.

Instructions du GPT :

• « Tu es un assistant commercial connecté à notre CRM HubSpot »
• « Quand on te demande des informations sur un contact ou une opportunité, utilise l’API HubSpot »
• « Avant d’ajouter une note, reformule-la et demande confirmation »
• « Ne modifie jamais le statut d’un deal ni les coordonnées d’un contact »

Les résultats

L’utilisateur peut demander :

• « Quels sont mes deals en négociation de plus de 50 000 euros ? »
• « Montre-moi les contacts de l’entreprise Durand & Fils »
• « Ajoute une note au contact Marie Leroy : appel du 15 mars, intéressée par l’offre Premium »

Le GPT interroge HubSpot, formate les résultats et exécute les actions autorisées.

Cas 2 : GPT connecté à un calendrier (Google Calendar)

Le besoin

Une assistante de direction veut gérer le calendrier de son dirigeant par conversation.

La configuration

Schéma OpenAPI : 4 endpoints

• GET /events : lister les événements d’une période
• POST /events : créer un événement
• PUT /events/{id} : modifier un événement existant
• DELETE /events/{id} : annuler un événement

Authentification : OAuth 2.0 avec Google. Scope : calendar.events (lecture + écriture sur les événements uniquement, pas les paramètres du calendrier).

Instructions du GPT :

• « Tu es un assistant de planification connecté à Google Calendar »
• « Avant de créer ou modifier un événement, résume l’action et demande confirmation »
• « Ne supprime jamais un événement sans double confirmation »
• « Vérifie toujours les conflits d’horaire avant de proposer un créneau »

Les résultats

L’utilisateur peut demander :

• « Qu’est-ce que j’ai demain après-midi ? »
• « Place une réunion avec l’équipe marketing mardi à 14h pendant 1h »
• « Décale le point avec Pierre de 10h à 11h »

Le GPT vérifie les disponibilités, propose une action et attend la confirmation avant d’agir.

Cas 3 : GPT connecté à une base de données (Airtable)

Le besoin

Une équipe produit veut interroger sa base de tickets et de feedbacks clients sans maîtriser les filtres Airtable.

La configuration

Schéma OpenAPI : 2 endpoints

• GET /records : lister les enregistrements avec filtres et tri
• POST /records : créer un nouvel enregistrement

Authentification : clé API Airtable (Bearer token), accès restreint à la base « Feedbacks Produit ».

Instructions du GPT :

• « Tu es un assistant produit connecté à notre base Airtable de feedbacks »
• « Quand on te pose une question sur les feedbacks, interroge la base avec les filtres appropriés »
• « Présente les résultats sous forme de tableau avec colonnes : date, client, catégorie, résumé »
• « Tu peux créer de nouveaux tickets mais jamais modifier ou supprimer les existants »

Les résultats

L’utilisateur peut demander :

• « Combien de bugs ont été remontés ce mois-ci ? »
• « Quels sont les feedbacks les plus récents sur la fonctionnalité de facturation ? »
• « Crée un ticket : bug d’affichage sur la page de paiement, signalé par le client Dupont le 28 mars »

Les patterns communs

En analysant ces trois cas, des patterns émergent :

Lecture libre, écriture contrôlée

Les trois GPTs peuvent lire librement mais demandent une confirmation avant d’écrire. C’est la règle d’or des GPTs connectés.

Des instructions qui mentionnent les Actions

Le GPT ne devine pas quand utiliser une Action. Vos instructions doivent explicitement indiquer : « Quand l’utilisateur demande X, utilise l’action Y. »

Un périmètre limité

Aucun des trois GPTs n’expose l’intégralité de l’API. Ils se limitent aux endpoints utiles pour leur cas d’usage.

Mise en pratique

1. Identifiez un outil que vous utilisez quotidiennement et qui dispose d’une API
2. Définissez 2-3 cas d’usage concrets (les questions que vous posez le plus souvent)
3. Créez un schéma OpenAPI minimal avec les endpoints nécessaires
4. Configurez l’authentification appropriée (clé API ou OAuth)
5. Ajoutez des garde-fous dans les instructions pour les opérations d’écriture
6. Testez avec des requêtes réelles

Erreurs courantes

• Connecter sans cas d’usage clair : ne connectez pas une API « au cas où ». Partez de vos besoins réels.
• Autoriser l’écriture sans confirmation : un GPT qui crée ou modifie des données sans validation peut causer des dégâts.
• Ne pas gérer les erreurs API : si l’API est indisponible ou retourne une erreur, votre GPT doit savoir quoi dire.
• Exposer trop d’endpoints : chaque endpoint consomme du contexte. Concentrez-vous sur les 2-5 plus utiles.

Points clés

• Les GPTs connectés à des outils réels résolvent des problèmes concrets au quotidien
• Suivez le pattern « lecture libre, écriture contrôlée » — toujours confirmer avant de modifier
• Mentionnez explicitement les Actions dans vos instructions pour que le GPT sache quand les utiliser
• Limitez les endpoints au strict nécessaire et gérez les cas d’erreur
• Commencez simple (un outil, 2 endpoints) et enrichissez progressivement