Claude écrit votre code, mais qui fait tourner votre plateforme de données ?

Si votre équipe marketing, votre service IT ou votre responsable des opérations a commencé à construire une solution de BI ou de reporting avec Claude ou un autre outil d’IA, les premières étapes ont probablement dépassé les attentes. Quelques prompts, une connexion de données fonctionnelle, un graphique qui s’affiche avec de vraies données. C’est indéniablement impressionnant et on comprend facilement pourquoi l’abonnement à une plateforme commence à sembler superflu.

Pour une source de données unique, un rapport qui n’a pas besoin d’être actualisé au-delà de quelques semaines, et une équipe disposant d’un développeur capable de maintenir du code personnalisé indéfiniment, construire avec Claude est une option tout à fait légitime. Le code fonctionnera, et la première version tourne généralement sans nécessiter beaucoup d’attention. Les difficultés apparaissent plus tard : quand le périmètre s’élargit, quand les clients commencent à poser des questions sur leurs données, ou quand un audit de conformité révèle des lacunes dans une infrastructure qui n’a jamais été conçue pour ça.

Ce qu’il faut comprendre avant d’aller plus loin, c’est ce qui se passe réellement en coulisses. Les agents IA progressent rapidement. Claude dispose désormais de connecteurs natifs et de MCPs qui étendent ce qu’il est possible de faire directement dans l’outil. Mais pour la plupart des workflows de données en production, la réalité reste la même : ce code a besoin d’un serveur pour s’exécuter, d’identifiants toujours valides, d’un planificateur qui détecte les échecs à 3h du matin, et de quelqu’un capable de corriger la transformation qui casse quand la source change de format en amont. Rien de tout cela ne s’accompagne du code généré.

Cet article cartographie les lacunes existantes. L’objectif est une lecture équilibrée, utile que vous soyez en cours de développement, en phase d’évaluation, ou simplement en train d’essayer d’y voir plus clair.

A retenir

• La connaissance opérationnelle reste chez celui qui a tout construit : credentials API, logique de l’ordonnanceur, transformations fragiles. Quand il part, elle ne se transfère pas automatiquement.
• La sécurité n’est pas préconfigurée : chiffrement, certificats SSL, journaux d’audit… tout doit être implémenté par votre équipe, ou ça ne l’est tout simplement pas.
• Une démo qui affiche un graphique n’est pas un système en production. La production, c’est des jobs qui relancent en cas d’échec, des accès cloisonnés par profil, et des données archivées depuis le premier jour.
• Les premières semaines semblent toujours prometteuses. Les vraies questions émergent six mois plus tard.

Avant de vous lancer, neuf domaines méritent d’être passés en revue : intégration des données, transformation, stockage, ordonnancement, tableaux de bord, alertes, sécurité, scalabilité et coûts. Cet article vous guide à travers chacun d’eux.

À qui s’adresse cet article :

Ce que Claude et les agents IA peuvent réellement faire avec vos données

Le tableau ci-dessous ne sous-estime pas ce qui est possible. Claude et les autres agents IA peuvent gérer ces six tâches. Cependant, ce que chaque entrée a en commun, c’est le même mécanisme sous-jacent : l’agent écrit du code, qu’il s’agisse d’un script Python, d’une requête SQL, d’un fichier HTML ou d’un cron job. Mais ce code n’est qu’un point de départ, pas un système opérationnel.

Tâche	Ce que Claude peut faire	Ce qui reste à votre charge
Connexion aux sources de données	Oui, mais indirectement : les agents peuvent écrire du code (Python, SQL) pour extraire des données depuis des API, des bases de données ou des fichiers (CSV/Excel).	Pas de connecteurs natifs. Vous fournissez les identifiants et les accès. Pas d’intégrations préconstruites pour Salesforce, Google Ads, etc.
Extractions récurrentes	Oui : les agents peuvent générer des scripts (ex. Python + cron ou Airflow) pour planifier les extractions.	Pas de planificateur intégré. Nécessite un serveur ou un environnement d’exécution externe (ex. GitHub Actions).
Nettoyage des données	Oui : les agents peuvent écrire des scripts Python (Pandas), SQL ou R pour nettoyer et transformer les données.	Pas d’interface visuelle. Chaque règle de transformation vit dans du code que votre équipe écrit et maintient.
Création de tableaux de bord	Partiellement : les agents peuvent générer des tableaux de bord statiques (ex. HTML/JS avec Plotly, D3.js) ou du code pour des outils comme Streamlit.	Pas de filtres interactifs ni de drill-downs sans outillage supplémentaire. Pas de gestion des utilisateurs ni de contrôles d’accès.
Publication des tableaux de bord	Oui : les agents peuvent générer des fichiers HTML/JS partageables ou déployer sur GitHub Pages/Netlify.	Pas d’authentification ni de gestion des permissions. Toute personne disposant du lien voit tout.
Alertes et notifications	Oui : les agents peuvent écrire des scripts pour envoyer des e-mails ou des messages Slack quand les données remplissent certaines conditions.	Pas de monitoring en temps réel. Nécessite des déclencheurs externes comme des cron jobs ou des webhooks.

Jusqu’où pouvez-vous réellement remonter dans l’historique ?

La plupart des API sources ne conservent pas des années de données accessibles. Google Ads, la majorité des CRM, la plupart des plateformes d’analytics : l’API expose généralement une fenêtre glissante de soixante à quatre-vingt-dix jours. Si le pipeline construit avec Claude ne tournait pas en archivant depuis le début, cette fenêtre est déjà derrière vous. Aucune requête ne peut récupérer des données qui n’ont jamais été capturées.

Claude peut générer l’architecture pour le stockage historique et écrire le code pour l’alimenter. Ce qu’il ne peut pas faire, c’est provisionner la base de données, la maintenir opérationnelle, gérer les changements de schéma quand les éditeurs mettent à jour leur structure de données, ou vérifier que l’archivage a bien fonctionné sur chaque période que vous souhaitez analyser. Une plateforme managée s’en charge en continu. Dans un développement sur mesure, celui qui détient les clés du système porte la responsabilité.

Avant de vous lancer dans le développement, posez-vous ces questions

Avant de construire une solution de BI ou de reporting de zéro avec Claude, il est utile de prendre le temps d’évaluer les principaux domaines que la solution devra couvrir. Tous les domaines ne seront pas aussi critiques selon votre situation, mais les passer en revue avant d’écrire la première ligne de code permet de faire remonter des hypothèses beaucoup plus difficiles à corriger une fois le système en production.

Les questions ci-dessous sont organisées par domaine. Chaque section comprend un ensemble de questions spécifiques à vérifier, suivi du contexte qui leur donne leur importance.

1. Intégration des données et connecteurs

• Quelles sources de données allez-vous connecter, et combien ?
• Qui gère les identifiants, et que se passe-t-il quand ils expirent ou doivent être renouvelés ?
• Quel est le plan quand une API source évolue ou commence à appliquer des limites de débit ?

Chaque source que votre pipeline touche correspond à un script que Claude a écrit une fois et que votre équipe maintient à partir de là. Quand Google Ads met à jour son API, ce qui arrive régulièrement, ce script se casse et arrête de récupérer des données en silence, sauf si quelqu’un a construit un système de monitoring. Qui le corrige, dans quel délai, et cette réponse change-t-elle quand la personne qui l’a écrit est indisponible ?
La gestion des identifiants sur plusieurs sources est une question connexe facile à différer : les tokens OAuth expirent, les clés API sont renouvelées, et quand quelqu’un qui avait un accès quitte l’équipe, ses identifiants doivent être révoqués. Dans un développement sur mesure, ce processus n’existe que si quelqu’un l’a explicitement construit.

2. Transformation et nettoyage des données

• Comment la logique de transformation sera-t-elle maintenue quand les champs sources changent ?
• Qui peut modifier les règles métier, et cela nécessite-t-il un développeur ?
• Que se passe-t-il quand de mauvaises données entrent dans le pipeline ?

Claude peut écrire une logique de transformation sophistiquée : déduplication, conversion de types, jointures multi-sources, gestion des valeurs nulles. La question la plus délicate est ce qui se passe six mois plus tard quand une source change un nom de champ, ou quand un client demande à ajuster le calcul du chiffre d’affaires. Chaque modification implique de retrouver le bon script, de l’éditer, de le tester et de le redéployer. Il n’existe pas d’interface permettant à un chargé de compte non technique d’effectuer ce changement lui-même.
Les données incorrectes représentent le risque associé : les doublons et les valeurs nulles dans les champs clés ne génèrent pas d’erreur dans un pipeline personnalisé. Ils arrivent dans le tableau de bord et sont remarqués, si tant est qu’ils le soient, par celui qui relit les chiffres avant un appel client.

3. Stockage et données historiques

• Où les données historiques seront-elles stockées, et qui possède cette infrastructure ?
• Le pipeline a-t-il été conçu pour archiver en continu dès le premier jour ?
• Le reporting nécessite-t-il des données en série temporelle, comme des instantanés quotidiens ou hebdomadaires ?

Claude peut écrire le SQL pour créer une base de données historique et les scripts pour l’alimenter, mais la base de données doit être provisionnée et maintenue par votre équipe. La plupart des API sources n’exposent qu’une fenêtre glissante de soixante à quatre-vingt-dix jours. Si l’archivage ne tournait pas depuis le début, cet historique a disparu et ne peut pas être reconstitué. Et sans historique, les instantanés quotidiens de campagne, les bilans hebdomadaires de performance ou les comparaisons mois sur mois deviennent impossibles : ces analyses nécessitent des données capturées et stockées au fil du temps.

Un pipeline qui se contente de récupérer l’état courant des données ne peut pas répondre à ces questions rétroactivement.

4. Planification et automatisation

• Le planificateur tourne-t-il dans un environnement de production, ou quelqu’un déclenche-t-il les jobs manuellement ?
• Que se passe-t-il quand un job planifié échoue silencieusement ?
• Comment les dépendances entre jobs sont-elles gérées quand un processus doit se terminer avant qu’un autre démarre ?

Claude peut générer un cron job ou un DAG Airflow, mais l’environnement dans lequel ces jobs s’exécutent doit exister en dehors de la conversation avec l’IA. Les données peuvent cesser de se rafraîchir sans aucune erreur visible, et le premier signe est souvent un client qui demande pourquoi les chiffres de cette semaine sont identiques à ceux de la semaine dernière. La gestion des échecs doit être explicitement construite : le pipeline se relance-t-il automatiquement, et quelqu’un est-il notifié dans le cas contraire ?

La gestion des dépendances est le problème le plus subtil : la tâche B s’exécute sur des données que la tâche A n’a pas encore terminé de produire, et les résultats sont faux d’une façon difficile à tracer sans connaître l’architecture.

5. Tableaux de bord et visualisation

• Les tableaux de bord seront-ils statiques ou interactifs, avec des filtres et des drill-downs ?
• Comment les permissions utilisateurs sont-elles gérées, et chaque client peut-il voir uniquement ses propres données ?
• Comment les tableaux de bord restent-ils à jour, et qu’est-ce qui déclenche un rafraîchissement ?

L’écart entre un tableau de bord généré par Claude et un tableau de bord prêt pour un client est souvent plus grand qu’il n’y paraît. Des graphiques statiques sans filtre de date, des applications où tous les utilisateurs voient les mêmes données, et des liens partagés sans contrôle d’accès fonctionnent bien comme prototypes internes.

Le reporting destiné aux clients nécessite généralement des droits d’accès granulaires : chaque utilisateur ne doit voir que ses propres campagnes et chiffres, et non l’intégralité des données via un simple lien partagé. À mesure que la base de clients grandit, ajouter un nouveau client à une couche d’accès personnalisée implique de toucher au code à chaque fois, plutôt que d’ajouter un utilisateur dans une plateforme.

6. Alertes et notifications

• Les clients peuvent-ils configurer leurs propres seuils d’alerte, ou chaque modification passe-t-elle par un développeur ?
• Le monitoring fonctionne-t-il en temps réel, ou sur une vérification planifiée qui peut accuser plusieurs heures de retard ?
• Quels canaux doivent être pris en charge, et cela est-il susceptible d’évoluer ?

Claude peut écrire un script d’alerte qui surveille une condition et envoie un message Slack, ce qui couvre bien le cas de base. Les questions qui émergent ensuite concernent le self-service : les clients peuvent-ils définir leurs propres seuils sans faire appel à un développeur, et le système détecte-t-il les changements au moment où ils se produisent ou avec un décalage ?
La couverture des canaux mérite également d’être réfléchie en amont. E-mail, Teams et SMS nécessitent chacun des intégrations séparées. Ajouter un nouveau canal après la mise en production n’est pas un simple paramètre à activer : c’est une tâche de développement qui entre en concurrence avec tout le reste du backlog.

7. Sécurité et conformité

• Le chiffrement est-il configuré au repos, en transit et au niveau applicatif ?
• Existe-t-il un journal d’audit capable d’indiquer qui a accédé à quelles données et quand ?
• Quelles exigences de conformité s’appliquent à vos clients, et lesquelles sont actuellement couvertes ?

Aucune infrastructure de sécurité dans un système développé avec Claude n’est configurée par défaut. Le chiffrement, les certificats SSL, les accès basés sur les rôles et la journalisation des audits doivent chacun être implémentés explicitement. Les rétrofit sur un système en production est significativement plus difficile que de les intégrer dès le départ.

Pour les agences qui gèrent des données clients soumises au RGPD ou à des exigences similaires, la question du journal d’audit mérite une attention particulière : si un client ou un régulateur demande qui a accédé à ses données et quand, ce journal existe ou il n’existe pas.

8. Scalabilité et performance

• L’architecture a-t-elle été conçue pour le nombre de sources et d’utilisateurs simultanés attendu, et pas seulement pour le cas d’usage initial ?
• Comment les données clients sont-elles isolées dans une configuration multi-tenant ?
• Quel est le plan de reprise quand le système tombe ?

Un pipeline personnalisé bien construit gérant quelques sources et une poignée d’utilisateurs peut tourner proprement. L’architecture qui fonctionne à cette échelle n’est souvent pas celle qui gère vingt sources et cinquante utilisateurs simultanés. Les performances des requêtes, l’accès concurrent aux tableaux de bord et l’isolation des données entre clients nécessitent chacun des décisions de conception délibérées, faciles à ignorer quand la première version est petite.
Pour les agences en particulier, la question du multi-tenant est centrale : dans un système personnalisé unique, séparer les données d’un client de celles d’un autre nécessite une logique de schéma explicite. Sans elle, une erreur de requête peut exposer des données entre clients.

9. Coûts et maintenance

• Quels sont les coûts récurrents complets, au-delà du développement initial ?
• Qui est spécifiquement responsable de la maintenance, et à quoi cela ressemble-t-il au quotidien ?
• Quel est le plan si la personne qui a construit et comprend le système n’est pas disponible ?

Le coût de développement est le chiffre qui tend à apparaître dans les comparaisons avec un abonnement à une plateforme. Les coûts qui n’apparaissent pas dans ces comparaisons sont les coûts récurrents : les heures développeur chaque mois pour maintenir le système opérationnel, le temps consacré aux mises à jour de dépendances et aux évolutions d’API, et l’effort nécessaire pour reconstruire la connaissance opérationnelle quand la personne qui la détient part.
Un stack de données dont la logique vit dans la tête d’une seule personne représente un risque business, quelle que soit la qualité de sa conception. La question qui mérite d’être couchée par écrit avant de démarrer : qui est propriétaire de la maintenance, ce que ce rôle couvre au quotidien, et quel est le plan de contingence si cette personne n’est pas disponible.

Que devient la solution développée avec l’IA au fil du temps ?

Les premiers mois d’un stack de données personnalisé se passent généralement bien. Celui qui l’a construit connaît chaque rouage, les corrections arrivent vite, et l’ensemble semble solide. Puis quelque chose de banal le casse : une API change son flux d’authentification, une bibliothèque publie une mise à jour incompatible avec l’existant, une source commence à formater différemment un champ de date. Chacun de ces problèmes nécessite quelqu’un qui sait exactement où chercher.

Les développements assistés par IA peuvent être mis en production rapidement, mais ils sont souvent documentés lentement. Le développeur qui a assemblé le système conserve la vraie carte mentale : quel job tourne en premier, où sont stockés les identifiants, ce que fait la logique de fallback, et quelles parties sont fragiles. Quand cette personne est absente, surchargée ou part, la carte ne se transfère pas automatiquement. Le code peut continuer à fonctionner, mais le modifier en toute sécurité devient beaucoup plus difficile sans le contexte qui lui a donné sa forme.

Et la montée en charge ajoute une nouvelle couche. Trois sources de données tournant proprement pour cinq utilisateurs est un problème gérable. Passer à vingt sources et cinquante utilisateurs implique de repenser l’isolation des jobs, les contrôles d’accès, la portée des identifiants et la gestion des échecs, chacun étant satisfaisant en one-off mais n’ayant pas été conçu pour ce volume. Ce chantier tend à arriver au moment où l’entreprise est en pleine croissance et n’a aucune marge dans le planning pour l’absorber.

Construire ou acheter a toujours été la vraie question

L’IA a réduit le coût de démarrage d’un développement sur mesure, ce qui permet à davantage d’équipes de tester des idées data qui nécessitaient auparavant des ressources humaines qu’elles n’avaient pas. C’est une bonne chose. Cependant, posséder un système de données en production implique d’être responsable de sa disponibilité, de sa posture de sécurité, de sa conformité réglementaire, de ses identifiants, de ses mises à jour de dépendances et de ses contrôles d’accès au fur et à mesure que les utilisateurs arrivent et repartent.

Les équipes qui préfèrent les plateformes managées ont réalisé qu’exploiter un système de données personnalisé, chaque jour, pour des utilisateurs qui en dépendent, est un métier différent de celui de l’assembler. ClicData regroupe ces responsabilités sous une seule plateforme : plus de 300 connecteurs natifs, un entrepôt de données intégré, une planification automatisée des pipelines, des tableaux de bord multi-tenants avec analytics embarqué, de la marque blanche et des contrôles d’accès basés sur les rôles. Ce que cela représente concrètement pour les équipes gérant des comptes clients à grande échelle est disponible sur la page de la solution pour les agences marketing.

Pour cartographier votre configuration actuelle face à ces questions avec quelqu’un qui connaît la plateforme, réserver une session avec l’équipe est le point de départ le plus direct.