Montrer le sommaire Cacher le sommaire
Toutes les pages produit le promettent : le logiciel s’intègre à vos outils. Derrière cette phrase se cachent des réalités très différentes, qui vont du fichier exporté à la main jusqu’à l’accès direct à votre base de données. Voici le vocabulaire et les questions à poser pour savoir ce que vous achetez vraiment.
Les sept niveaux d’intégration
| Niveau | Ce que ça permet | Mise en place | Ce qui casse quand ça casse |
|---|---|---|---|
| Export de fichier | Sortir des données à un instant donné pour les archiver ou les retraiter | Quasi nulle, c’est un bouton | Rien, mais les données sont périmées dès l’export |
| Import manuel | Charger un fichier dans l’autre outil | Faible, mais récurrente et chronophage | Doublons, colonnes mal associées, écrasements silencieux |
| Connecteur natif | Synchronisation prête à l’emploi entre deux outils précis | Faible : on autorise, on choisit quelques options | Le connecteur évolue sans vous : un champ disparaît, la synchronisation s’arrête |
| API | Échange programmatique sur mesure, dans les deux sens | Forte : développement, tests, maintenance | Changement de version côté éditeur, expiration de jeton, dépassement de quota |
| Webhook | Réaction immédiate à un événement, sans interrogation permanente | Moyenne : il faut une adresse capable de recevoir et traiter | Message perdu pendant une indisponibilité, ou rejoué en double |
| Plateforme d’automatisation intermédiaire | Relier plusieurs outils sans développer | Moyenne, mais l’assemblage devient vite complexe | Un maillon tombe, toute la chaîne s’arrête, et le diagnostic est difficile |
| Accès direct à la base | Tout lire, tout écrire, sans garde-fou applicatif | Variable, mais rarement proposée et rarement souhaitable | Corruption de données, contournement des règles métier, incompatibilité à la moindre mise à jour |
Comment lire ce tableau
Les trois premiers niveaux sont des transferts. Rien ne se passe tant qu’un humain n’agit pas, ou tant que le connecteur ne déclenche pas sa synchronisation périodique. C’est le régime le plus courant pour les outils du quotidien d’une petite structure : Gmail ou Outlook pour la messagerie, Google Agenda pour le planning, WhatsApp Business et Instagram pour les messages entrants, HubSpot ou Pipedrive pour le suivi commercial, Stripe pour les encaissements. Le coût d’installation est faible, le coût d’usage est récurrent, et le risque est celui de la donnée obsolète ou dupliquée.
Les niveaux API et webhook sont des échanges. L’API vous permet de demander : vous appelez le service tiers quand vous voulez savoir quelque chose ou faire quelque chose. Le webhook vous permet d’être prévenu : le service tiers vous envoie un message dès qu’un événement se produit, sans que vous ayez à demander. Les deux sont complémentaires plus que concurrents. Ils exigent du développement et, surtout, de la maintenance : une API est un contrat que l’éditeur peut faire évoluer.
La plateforme d’automatisation intermédiaire — Zapier, Make, n8n — est un compromis : elle évite le développement, mais ajoute un tiers dans la chaîne, avec sa propre facturation, ses propres limites et sa propre disponibilité. Elle crée aussi une dépendance peu visible : la logique de votre entreprise finit par vivre dans des scénarios que personne ne documente.
L’accès direct à la base contourne l’application. C’est puissant et c’est presque toujours une mauvaise idée : les règles de cohérence, les contrôles de saisie et l’historique vivent dans l’application, pas dans la base.
Lire ou écrire : la ligne de partage qui compte
Une intégration en lecture seule consulte des données sans jamais les modifier. Le pire scénario est un affichage faux, une statistique erronée, une décision prise sur une base périmée. C’est ennuyeux, c’est rarement irréversible.
Une intégration en écriture crée, modifie ou supprime des données chez le tiers : elle ajoute une fiche client, change un statut, envoie un message, déplace un fichier. Le pire scénario n’est plus un affichage faux, c’est une action réelle, visible par vos clients, et parfois impossible à annuler. Une boucle mal conçue peut créer des centaines d’enregistrements en quelques minutes. Une correspondance de champs inversée peut écraser une valeur renseignée par une valeur vide.
Conséquence pratique : traitez lecture et écriture comme deux décisions distinctes. Commencez en lecture seule, observez, puis ouvrez l’écriture champ par champ, sur un périmètre restreint, avec une possibilité de revenir en arrière.
L’authentification déléguée, en langage simple
Quand un outil doit accéder à un autre outil en votre nom, deux méthodes existent.
La mauvaise : vous lui donnez vos identifiants. Il se connecte en se faisant passer pour vous. Il a exactement vos droits, sur tout. Vous ne savez pas ce qu’il fait, vous ne pouvez pas limiter son périmètre, et pour lui retirer l’accès il faut changer votre mot de passe — ce qui déconnecte tout le reste au passage.
La bonne : l’autorisation déléguée, dont OAuth est le standard le plus répandu — c’est le mécanisme derrière les boutons « Se connecter avec Google » et « Se connecter avec Microsoft ». Le principe tient en trois temps. Vous êtes redirigé vers le service tiers, sur son propre site. Vous vous authentifiez chez lui, pas chez l’éditeur. Il vous affiche ce que l’application demande, et vous acceptez ou vous refusez. L’éditeur reçoit alors un jeton d’accès : une clé limitée, datée, révocable, qui n’est pas votre mot de passe et qui ne permet que ce que vous avez accordé.
Pourquoi demander votre mot de passe est un signal d’alerte
Un éditeur sérieux n’a aucune raison de stocker votre mot de passe d’un service tiers. S’il le demande, cela signifie l’une de ces choses : il n’a pas implémenté l’intégration proprement, il conserve un secret qu’il ne devrait pas détenir, ou il simule une intégration en pilotant l’interface du service tiers à votre place. Dans les trois cas, vous perdez la traçabilité et la révocabilité. Vous enfreignez peut-être aussi les conditions d’utilisation du service tiers, ce qui peut entraîner la suspension de votre compte.
Une nuance utile : certains outils fonctionnent avec une clé d’API que vous générez vous-même chez le tiers. Ce n’est pas un mot de passe, c’est acceptable, à condition que cette clé puisse être limitée en périmètre et révoquée indépendamment.
Le périmètre d’autorisation
L’écran de consentement affiche des demandes précises. « Lire les fichiers d’un dossier que vous désignez » et « accéder à tous vos fichiers » sont deux mondes différents. « Envoyer des messages en votre nom » et « lire l’ensemble de votre messagerie » aussi. Ces demandes s’appellent des périmètres.
Prenez le temps de lire cet écran. C’est le seul moment où l’information vous est présentée clairement, et le seul où vous avez un vrai pouvoir de refus. Si une application demande un accès large alors que la fonctionnalité annoncée est étroite, demandez à l’éditeur de justifier chaque périmètre. Une réponse du type « c’est nécessaire techniquement », sans précision, n’est pas une réponse.
Vérifier et révoquer
La plupart des suites bureautiques et des services professionnels proposent, dans les paramètres de compte, une page listant les applications tierces autorisées, ce qu’elles peuvent faire et depuis quand. Chez Google, l’entrée s’appelle « Applications tierces avec accès au compte », dans les paramètres de sécurité ; chez Microsoft, « Applications et services auxquels vous avez accordé l’accès ». Ailleurs, cherchez « applications connectées », « accès des tiers » ou « sécurité ». Vous y révoquez un accès en un clic, sans changer votre mot de passe et sans affecter les autres intégrations.
Deux réflexes à instaurer : une revue de cette liste à intervalle régulier, et une révocation systématique au départ d’un collaborateur ou à l’arrêt d’un abonnement. Une autorisation oubliée reste active.
Les limites dont personne ne parle avant la signature
Les quotas d’appels. Les services tiers limitent le nombre de requêtes par période. Une fois la limite atteinte, les appels sont refusés jusqu’à la fenêtre suivante. Ces limites ne sont pas les mêmes selon l’offre à laquelle vous avez souscrit chez le tiers. Une intégration qui fonctionne en démonstration sur trente fiches peut s’écrouler sur trente mille.
Les délais de synchronisation. « Temps réel » veut rarement dire instantané. Un connecteur natif synchronise souvent par cycles. Demandez la fréquence réelle, et surtout ce qui se passe pendant l’intervalle : que voit un utilisateur qui consulte la fiche entre deux synchronisations ?
Les conflits. Si votre outil et l’outil tiers modifient la même fiche pendant le même intervalle, lequel gagne ? Trois politiques existent : le dernier qui écrit gagne, un système est déclaré maître, ou le conflit est signalé pour arbitrage humain. La première est la plus fréquente et la plus silencieuse : une modification disparaît sans que personne le sache.
Les pannes. Le service tiers sera indisponible un jour. Les questions à poser : les opérations sont-elles mises en file d’attente et rejouées, ou perdues ? Serez-vous alerté, ou découvrirez-vous le problème par un client mécontent ? Et pour les webhooks : que se passe-t-il si un message arrive deux fois ?
Huit questions à poser avant de brancher quoi que ce soit
- À quel niveau du tableau ci-dessus se situe cette intégration, précisément ?
- Lecture seule ou écriture ? Sur quels objets et quels champs exactement ?
- Quel mécanisme d’authentification ? Si ce n’est pas une autorisation déléguée ou une clé révocable, pourquoi ?
- Quels périmètres d’autorisation sont demandés, et à quoi sert chacun d’eux ?
- Quelle fréquence de synchronisation réelle, et quelle politique en cas de conflit d’édition ?
- Quel comportement en cas d’indisponibilité du service tiers : file d’attente, alerte, perte ?
- Qui assure le support quand la synchronisation s’arrête : l’éditeur, le tiers, ou aucun des deux ?
- Comment couper l’intégration, et qu’advient-il des données déjà transférées ?
Questions fréquentes
API et connecteur, est-ce la même chose ?
Non. L’API est l’interface technique exposée par un logiciel. Le connecteur est un produit fini construit par-dessus une API, pour un cas d’usage précis. Vous utilisez un connecteur sans écrire de code ; vous utilisez une API en développant, ou en payant quelqu’un pour le faire.
Faut-il un développeur pour intégrer deux outils ?
Pas nécessairement. Un connecteur natif ou une plateforme d’automatisation couvrent beaucoup de besoins courants. Le développement devient nécessaire quand la logique est spécifique à votre métier, quand les volumes sont importants, ou quand vous ne voulez pas dépendre d’un intermédiaire supplémentaire.
Une intégration en lecture seule présente-t-elle un risque ?
Oui, mais un risque de confidentialité, pas d’intégrité. Les données lues sortent de votre système et transitent chez un tiers. Vérifiez où elles sont stockées, combien de temps, et à quoi elles servent. Un accès en lecture à une messagerie professionnelle reste un accès très large.
Que faire si l’éditeur refuse de répondre à ces questions ?
Considérez le refus comme une réponse. Un éditeur qui maîtrise son intégration documente ses limites : elles figurent en général dans sa documentation technique publique. Demandez le lien plutôt qu’une réponse commerciale.
Note de méthode
Cet article ne cite volontairement aucun chiffre : quotas d’appels, délais de synchronisation et durées de validité des jetons varient selon l’éditeur, selon l’offre souscrite et selon la version de l’interface. Toute valeur générale serait fausse dans votre cas précis. Les seules sources fiables sont la documentation technique publique de chaque éditeur concerné et vos conditions contractuelles. Exigez-les avant de signer, pas après.
