À l'article 15, on a installé le MCP Google Drive. Claude Code peut maintenant lire mes fichiers, en créer, en modifier. Ce n'est plus un outil qui répond dans une fenêtre. C'est un agent qui agit dans un endroit où vivent mes vrais documents.
J'ai voulu cette porte ouverte. C'est pour ça que j'ai installé le MCP. Mais une porte ouverte, ça se gère. Pas avec de la peur, pas avec un audit de sécurité en douze points. Avec trois questions simples : qu'est-ce que je laisse Claude faire seul, qu'est-ce que je valide d'abord, qu'est-ce que je ne lui donne jamais.
Ces trois questions, elles ne changent jamais, à chaque projet. Ce qui change, c'est la réponse, parce que chaque projet a des zones différentes où une erreur coûte cher.
Le diff, dix secondes, quatre-vingt-dix pour cent des accidents évités
On a vu le diff à l'article 5. C'est le moment où Claude propose une modification et où tu vois exactement ce qui va changer avant de valider. Les lignes supprimées en rouge, les lignes ajoutées en vert. Rien ne se passe tant que tu n'as pas dit oui.
Pour quelqu'un qui vient d'Excel ou d'Airtable, ce réflexe n'existe pas. Dans Excel, tu modifies une cellule, c'est fait. Il n'y a pas d'étape intermédiaire. Tu peux faire Ctrl+Z si tu t'en rends compte tout de suite, mais si tu fermes le fichier et que tu le rouvres le lendemain, c'est trop tard.
Le diff, c'est l'inverse. Chaque modification passe par une étape de validation explicite. Claude te montre ce qu'il veut faire. Tu relis. Tu acceptes ou tu refuses. Ça prend dix secondes, et ça évite la majorité des accidents.
Je dis « accidents » et pas « attaques » parce que le risque réel, au quotidien, ce n'est pas que Claude fasse quelque chose de malveillant. C'est qu'il fasse quelque chose de logique dans son contexte mais d'absurde dans le mien. Il ne connaît pas mes conventions de nommage de fichiers Google Drive. Il ne sait pas que tel dossier est partagé avec un client. Il ne sait pas que tel fichier est une pièce comptable qu'il ne faut pas toucher.
Sur Pimpela, j'ai pris l'habitude de relire chaque diff, même quand la modification a l'air anodine et souvent, je ne comprends pas vraiment ce qu'il fait soyons honnetes. Mais, parfois, je comprends, et mon oeil s'aiguise. Un soir, Claude proposait de renommer une variable d'environnement pour la rendre plus lisible. Bonne idée en soi. Sauf que cette variable était référencée dans ma configuration Supabase, ma base de données en ligne. Si j'avais validé sans relire, l'application aurait perdu sa connexion à la base. Dix secondes de lecture m'ont évité une heure de débogage.
Le diff n'est pas un outil de sécurité au sens informatique. C'est un réflexe de pilotage. Le même que celui qu'on a quand on relit un virement avant de le valider, ou quand on vérifie les destinataires d'un e-mail avant d'appuyer sur Envoyer.
Ce qu'on laisse Claude faire seul
Tout ce qui est réversible.
Sur Pimpela, je laisse Claude modifier du code dans mon projet local, c'est-à-dire sur mon macbook, sans que ça affecte la version en ligne. Il peut réécrire un composant d'interface, restructurer un fichier, ajouter une fonction. Si le résultat ne me plaît pas, je reviens en arrière en une commande. Git, le système de versionnage qu'on a vu à l'article 7, garde tout l'historique. Rien n'est perdu.
Le critère n'est pas « est-ce que je fais confiance à Claude ». Le critère, c'est « est-ce que je peux défaire ce qu'il a fait sans effort particulier ». Si oui, je le laisse avancer. Ça me fait gagner du temps sur les tâches répétitives, les ajustements d'interface où je sais ce que je veux mais où l'écriture ligne par ligne serait fastidieuse.
Je laisse aussi Claude créer des fichiers dans mon projet. Des composants, des pages, des utilitaires. Créer un fichier, c'est réversible par définition : on le supprime.
Ce que je ne laisse pas faire « seul » même dans cette zone-là : les modifications qui touchent à plusieurs fichiers en même temps de manière coordonnée. Si Claude veut modifier la structure de données ET l'interface ET la logique métier en une seule passe, je préfère découper. Alors j'insiste pour qu'il decoupe son travail en phase. Une chose à la fois, un diff à la fois. C'est plus lent, mais chaque étape reste compréhensible.
Ce qu'on valide d'abord
Tout ce qui touche à des données persistantes ou à des services partagés.
Ma base de données Supabase, c'est l'endroit où vivent les données de Pimpela : les comptes utilisateurs, les projets déco, les résultats générés. Si Claude modifie la structure de cette base, par exemple en ajoutant une colonne ou en changeant le type d'un champ, l'action n'est pas toujours réversible simplement. Une colonne supprimée, ce sont des données perdues. Un type de champ changé, ce sont potentiellement des données abimées.
Quand Claude me propose une migration de base, c'est-à-dire une modification de la structure des tables, je lis le diff avec une attention particulière. Je regarde ce qui est supprimé. Je regarde ce qui est transformé. Si je ne comprends pas une ligne, je demande à Claude de m'expliquer avant de valider. Il le fait très bien, d'ailleurs. « Explique-moi ce que fait cette migration, ligne par ligne » est une de mes commandes les plus fréquentes.
Même logique pour tout ce qui touche à Google Drive via le MCP. Si Claude veut créer un fichier dans un dossier partagé avec quelqu'un d'autre, je valide d'abord. Si Claude veut modifier un fichier existant, je valide d'abord. Le partage crée de la conséquence : ce que Claude fait dans un dossier partagé est visible par d'autres personnes, immédiatement.
La règle pratique que j'applique : si l'action a des conséquences en chaîne, c'est-à-dire si elle peut affecter autre chose que le fichier ou la ligne qu'elle touche directement, je relis deux fois.
Ce qu'on ne donne jamais
L'accès à des outils qu'on ne maîtrise pas soi-même.
Il existe des MCP pour à peu près tout. Des MCP pour se connecter à des outils bancaires, à des outils de paie, à des CRM, à des plateformes publicitaires. Techniquement, rien n'empêche de les installer. Pratiquement, j'en ai refusé plusieurs.
Mon critère : est-ce que je comprends ce que l'outil fait quand je l'utilise moi-même, à la main ? Si oui, je peux évaluer ce que Claude propose d'y faire. Si non, je ne peux pas relire le diff de manière utile. Je verrai des lignes de code qui décrivent une action dans un système que je ne connais pas assez pour juger si l'action est correcte.
C'est exactement le problème. Le diff ne protège que si on le comprend. Si je connecte Claude à un outil de paie et qu'il me propose de « mettre à jour le champ compensation_amount pour les entrées de type recurring », je n'ai aucun moyen de savoir si c'est juste ou catastrophique sans aller vérifier manuellement dans l'outil. Et si je dois vérifier manuellement chaque action, autant la faire moi-même.
Je n'ai pas installé de MCP pour mes outils financiers. Pas parce que Claude ferait quelque chose de malveillant. Parce qu'une erreur dans un endroit que je ne maîtrise pas est une erreur que je ne verrai pas passer. La compétence de relecture suppose une compétence sur le sujet relu.
Pour Pimpela, mes MCP actifs sont uniquement les outils de développement (Supabase). Ce sont des domaines où je sais lire ce que Claude propose. Le jour où j'aurai suffisamment de maîtrise sur un autre outil pour juger ses propositions, je pourrai l'ajouter.
Le budget comme réflexe de sécurité
Lorsque je connecte un outil à l'API Anthropic ce n'est pas inclus dans mon abonnement Claude. Donc cela consomme des tokens à chaque interaction, et donc des euros. Plus la conversation est longue, plus le contexte est riche, plus ça coûte. Sur Anthropic, on peut poser une limite de dépense mensuelle sur son compte. Reflexe de financière, je l'ai fait dès le début. Et dès que je mets en place un outil incluant l'API Anthropic, je demande à Claude de me suivre les couts de chaque utilisation et de me cree un espace interface admin pour suivre qu'est ce qui consomme quoi dans mon appli.
Ce n'est pas un sujet de sécurité informatique. C'est du pilotage. Le même réflexe que poser un plafond sur une carte bancaire ou vérifier ses relevés en fin de mois. Je regarde ma consommation Anthropic une fois par semaine, sur le tableau de bord de mon compte. Ça me prend deux minutes. Je vois combien j'ai dépensé, sur quels projets, et si la courbe correspond à mon usage réel.
Une fois, j'ai vu un pic que je ne m'expliquais pas. En creusant, j'ai réalisé que j'avais laissé tourner une conversation très longue sur Pimpela sans la couper, et Claude renvoyait l'intégralité du contexte à chaque échange. La solution était simple : couper la conversation et en ouvrir une nouvelle avec un contexte ciblé. Mais sans le réflexe de vérifier la conso, je ne l'aurais pas vu avant la facture.