Git dans Google Drive avec une IA qui code : 63 105 fichiers en attente, dont 1 082 utiles

Le montage de départ

Le poste qui encaisse tout ça est un PC de 2014, à son cinquième SSD. J'ai d'ailleurs perdu mon premier disque dur à Noël 1995, et je me croyais vacciné depuis.

• Google Drive pour ordinateur, en mode miroir, avec tous mes projets dedans : une copie complète de chaque fichier sur le disque et en ligne (Google explique les deux modes).
• git pour l'historique de chaque projet, puis GitHub en privé pour certains, mais rien pour d'autres (le code de clients, mes dossiers administratifs).
• Claude Code, l'application de bureau, où chaque session travaille dans un worktree : une copie de travail complète du projet, sur sa propre branche, afin que dix sessions avancent sans se marcher dessus. J'en ai d'ailleurs parlé côté outils dans mes 60 skills Claude Code.
• Enfin, une connexion 4G, dont la liaison montante est le goulot de tout le reste.

Si un mot vous échappe, le glossaire de l'IA en a cinquante ; il y a aussi un mini-glossaire git dans la FAQ en bas de page.

Git dans Google Drive : deux archivistes, un seul classeur

Un dépôt git, c'est un dossier caché .git : des milliers de petits fichiers (un par version de chaque fichier), des « références » qui disent où en est chaque branche, et des verrous posés pendant une opération.

Mais Drive veut envoyer chacun de ces petits fichiers à chaque changement, alors qu'un seul commit en crée des dizaines. En plus, Drive dépose ses propres fichiers dans les dossiers qu'il gère : des desktop.ini, qui servent à afficher une icône dans l'Explorateur Windows. Il en met aussi dans .git. J'en ai compté 559 dans des dossiers .git le 2 août, puis 256 dans un seul dépôt le 9 septembre.

Autrement dit, deux archivistes rangent le même classeur, chacun avec son système, et l'un colle des étiquettes sur les fiches de l'autre.

Le symptôme qui ment

Lorsque git tombe sur un desktop.ini dans la liste des branches, il s'arrête et le dit : fatal: bad object refs/desktop.ini. Mais le problème commence quand un script cache ce message. Le 9 septembre, par exemple, un inventaire qui jetait les erreurs et comptait les lignes m'a répondu « 0 objet », alors qu'il y en avait 1 064. Trois fichiers d'icône dans refs/ suffisaient à tout fausser.

Le rituel qui ne vérifiait rien

D'abord, dès le 18 mai, la règle était : mettre Drive en pause avant toute opération git. Puis, le 7 juin, c'est devenu un fichier-témoin quotidien et un hook qui bloquait le commit sans témoin.

Mais trois mois plus tard, en relisant le script, je découvre qu'il ne regardait rien de l'état de Drive. Il vérifiait plutôt qu'un fichier existait, un fichier que je posais moi-même chaque matin. De toute façon, la pause de Drive ne suspend que les transferts, tandis que le rapprochement local continue. Pendant trois mois, j'ai donc répondu « oui, Drive est en pause » à un script qui me croyait sur parole. Le rituel a finalement été retiré le 26 août.

La parade : sortir l'historique de Drive

git sait ranger l'historique ailleurs que dans le dossier du projet :

git init --separate-git-dir=D:/historiques/mon-projet.git

Le projet reste dans Drive, donc les fichiers qu'on lit et qu'on modifie sont synchronisés comme avant. En revanche, l'historique part dans un dossier local que Drive ne voit pas. Dans le projet, il ne reste alors qu'un fichier .git d'une ligne, un panneau « l'historique est là-bas » :

gitdir: D:/historiques/mon-projet.git

Plus d'objets, plus de références, plus de verrous sous Drive. Je l'ai fait dépôt par dépôt à partir du 8 juillet. Depuis le 26 août, tout nouveau dépôt naît d'ailleurs comme ça, et aujourd'hui un hook bloque un git init sous Drive sans l'option.

Le prix, que j'ai vu trois mois trop tard

Mais l'historique n'est plus dans le cloud. Pour les projets qui ont un dépôt GitHub, ce n'est pas grave, car GitHub en garde une copie. Sauf que pour les autres, l'historique n'existait plus qu'en un exemplaire, sur un disque local. Pourtant, personne ne l'a vu avant le 26 octobre : on y revient plus bas.

Deux nuances avant de crier au loup

• Aucune perte de données git n'est documentée chez moi. Dans les trois nettoyages (2 août, 9 septembre, 13 octobre), retirer les desktop.ini a d'ailleurs suffi et git fsck est ressorti propre. Le dépôt était inutilisable en apparence, pas détruit.
• Les verrous index.lock orphelins, je les ai d'abord mis sur le dos de Drive. Puis, le 2 août, j'en trouve un qui bloque tout dans le dossier d'historique, hors Drive. La cause est donc probablement un process git interrompu, pas Drive.

Il reste enfin un piège : ne déplacez pas l'historique d'un projet déjà ouvert dans l'application Claude. Le 13 octobre, j'ai externalisé sept dépôts d'un coup. Le lendemain, l'application refusait ces dossiers, car elle avait mémorisé l'ancien emplacement. J'ai donc tout annulé. Ces sept anciens dépôts gardent ainsi leur historique dans Drive, avec un double sur GitHub. Retenez plutôt ceci : l'option se pose à la création du dépôt, pas après.

Octobre : Drive perd sa mémoire, les copies de travail noient tout

Retour à la nuit du 8 octobre. Sans sa base, Drive ne sait plus qui est qui ; ses journaux et ses bases (ouvertes en lecture seule) racontent ensuite la suite.

Le « (1) » est presque toujours l'ancienne version

Lorsque le contenu d'un fichier diffère entre le disque et le cloud, Drive ne choisit pas. Il envoie plutôt la version locale comme nouveau fichier, puis redescend l'ancienne à côté, sous « nom (1) ». Ainsi, sur les 221 doublons d'octobre, 219 étaient l'ancienne version. J'en ai aussi recoupé 22 octet pour octet avec l'historique git.

Le fichier sans suffixe est donc le bon, après une perte de base. Mais hors perte de base, ne rien supposer : en août, lors du premier bug Drive (458 fichiers parasites, cause jamais trouvée), un « (1) » portait les données et l'original n'était qu'un fichier vide.

Voici aussi le reste de la liste :

• un dossier qui ne différait d'un autre que par la casse est redescendu en entier sous « (2) » : 548 Mo ;
• ensuite, les raccourcis Google Docs (.gdoc) inconnus de la base ont été copiés en ligne : 206 documents dupliqués, des formulaires en trois exemplaires, « Copie de Copie de… » ;
• le 11 octobre, en 6 h 12 : 38 180 fichiers créés en ligne, 16,2 Go redescendus ;
• et le meilleur : le 9 octobre, j'avais supprimé 18 copies de travail, environ 10 Go, afin de faire de la place. Mais Drive les a redescendues du cloud, car sans sa base il ne distingue plus « supprimé ici » de « jamais téléchargé ici ». Le ménage a donc été défait.

En revanche, aucun écrasement d'un fichier local par une vieille version n'apparaît dans les journaux, et quatre cas ont été contrôlés sur le disque.

Les copies de travail de l'IA

Pourtant, le vrai volume, ce n'était pas Drive : c'était moi, ou plutôt mes sessions.

Le 9 octobre, le disque D: n'avait plus que 8,6 Go libres. En cherchant pourquoi, j'ai alors trouvé environ 50 Go de worktrees, 85 copies de travail. 34 rien que pour ce site, à 1,2 Go chacune, parce que des vidéos, des PSD et des captures étaient suivis par git et recopiés dans chaque copie.

Tant que ces copies vivaient dans Drive, Drive devait donc envoyer chacune en entier. Ajoutez aussi les brouillons de l'IA, scripts jetables, extractions, node_modules, des fichiers qui changent sans arrêt. C'est comme si on demandait à La Poste de réexpédier chaque soir, en recommandé, tous les papiers froissés de la corbeille.

La file d'envoi du 13 octobre

En plus de la file, un seul dossier de brouillons comptait 348 216 entrées, 40 % de tout ce que Drive surveillait. Une petite partie seulement attendait d'être envoyée ce jour-là, mais Drive devait tout regarder.

Ce jour-là, je l'ai d'ailleurs dit à peu près en ces termes : on ne peut même pas exclure un dossier ou un type de fichier. Et c'est exact, puisque Drive en mode miroir n'a aucune exclusion, ni par dossier, ni par type.

Ce qui a marché

1. Geler, sauvegarder, diagnostiquer en lecture seule. D'abord, avant le moindre geste, une archive 7-Zip de 150,9 Go, testée, puis une copie du profil de Drive, enfin ses bases ouvertes en lecture seule.
2. Quarantaine, jamais de suppression par nom. Car treize fichiers de ce site s'appellent légitimement « quelque chose (1) ». Un script compare chaque doublon à l'original par empreinte et par date, le déplace hors de Drive avec un manifeste, et garde les copies plus récentes. Attention cependant : pour Drive, sortir un fichier du dossier revient à le supprimer en ligne (corbeille, 30 jours). C'est pourquoi on ne déplace qu'après comparaison.
3. Tout ce qui bouge beaucoup sort du dossier Drive. Ainsi, les worktrees vont dans un dossier local (c'est un réglage de l'application Claude), les brouillons dans un dossier local hors Drive, et les vidéos, PSD et captures sortent du suivi git. Un worktree de ce site est alors passé de 1,2 Go à 485 Mo.
4. Laisser Drive finir. Il s'est aussi redémarré seul plusieurs fois pendant son chargement.

Mais voici ce qui n'a pas marché, la même semaine :

• croire Drive planté pendant son chargement, puis redémarrer le PC par précaution : chargement remis à zéro ;
• relancer Drive par automatisation alors que je venais de le quitter proprement : il a tenu seize secondes ;
• annoncer 22 Go gagnés avant de mesurer, alors que la mesure a donné 16,4 Go.

Passer sur GitHub privé sans emporter ses secrets

Revenons ensuite en septembre : le 9, je passe quatre projets sur des dépôts GitHub privés. Le pôle cybersécurité reste toutefois exclu, car des dossiers d'incidents nominatifs n'ont rien à faire chez un hébergeur de code, même en privé. Mes dossiers administratifs restent aussi sans remote.

Auditer l'historique, pas l'état du jour

Un mot de passe supprimé au commit 12 part pourtant avec le commit 12. L'audit porte donc sur tout l'historique. Il a ainsi trouvé :

• un fichier .ppt de 106,5 Mo, au-dessus du plafond de 100 Mo de GitHub ;
• un mot de passe de démonstration en clair, à quatre endroits d'un même dépôt.

Pour ce dépôt, j'ai alors choisi de repartir sans historique : un seul commit neuf, les 59 commits d'origine gardés en local sur une branche jamais poussée. Puis, après chaque push, vérification côté GitHub : fichiers distants comparés aux fichiers locaux, un par un.

Trois contrôles qui ont menti dans le même audit

C'est la partie dont je suis le moins fier, mais aussi la plus utile.

1. L'outil. git grep recevait la liste des fichiers en argument, donc une ligne de commande trop longue pour Windows : il a répondu 0, alors qu'il y avait 596 résultats.
2. L'objet. git rev-list --objects --all répondait 0 objet, à cause des desktop.ini de Drive. Git affichait pourtant bien l'erreur, mais mon script l'envoyait dans /dev/null, puis comptait les lignes.
3. Le motif. Enfin, chercher « mot de passe » suivi de = ou de : ne trouvait le mot de passe de démonstration qu'à un de ses quatre emplacements.

Les deux premiers faux zéros, je les ai débusqués avec un témoin positif : avant de croire un « rien trouvé », chercher un mot dont on sait qu'il est là. Mon prénom, par exemple. Si l'outil ne le trouve pas, c'est donc l'outil qui est cassé.

Mais le témoin n'a pas vu le troisième. Il était vert, parce qu'il prouve que l'outil sait trouver, pas que le motif cherche la bonne chose. D'où un second passage avec un motif plus large, trié à la main.

Le cousin de cette erreur, c'est le succès qui ment :

git commit -m "miroir du jour" | tail -1

Le code de sortie de cette ligne est en fait celui de tail, qui réussit toujours. Ainsi, fin juillet, trois jours de commits de mon miroir de configuration ont échoué derrière un | tail, sans une alerte. Vérifiez l'effet (le commit existe, le fichier est en ligne), pas le message. Dans un script bash, ajoutez aussi set -o pipefail en tête : l'échec du commit remonte alors.

Le trou de l'audit

Le commit neuf, « propre, sans historique », a emporté un fichier que personne n'avait scanné : un export d'administration avec des identifiants, jamais suivi par git jusque-là, donc absent de l'historique audité. Je ne l'ai vu que trois semaines plus tard, le 2 octobre, puis retiré du suivi.

Un audit d'historique doit donc aussi regarder ce que le prochain commit va ajouter. Autrement dit, git status et les fichiers non suivis.

La limite du plan gratuit

Je voulais aussi interdire le force-push sur main. Mais sur un dépôt privé en plan gratuit, GitHub refuse la protection de branche (erreur 403, « Upgrade to GitHub Pro or make this repository public »). J'ai donc mis à la place un hook pre-push sur mon poste, qui refuse le force-push et la suppression de main, testé dans les deux sens. C'est toutefois un garde-fou local, contournable avec --no-verify, et pas un verrou côté serveur.

Comment un mot de passe voyage tout seul avec une IA qui code

Avec un assistant qui exécute des commandes, un secret écrit dans une commande ne reste pas dans la commande. Il est ensuite recopié :

1. d'abord dans le journal de la session, qui garde tout ce qui est tapé et affiché (chez moi, 839 journaux pour 2,9 Go le 24 octobre) ;
2. puis dans la sortie de la tâche ;
3. dans la liste des permissions, lorsqu'on a cliqué « toujours autoriser » : la commande, secret compris, devient une règle permanente, dans le fichier .claude/settings.local.json ;
4. ensuite dans chaque nouvelle copie de travail, qui recopie cette liste ;
5. aussi dans Drive, qui synchronise le tout ;
6. enfin, parfois, dans la mémoire de l'IA, qui résume ce qu'elle a appris, valeurs comprises.

C'est comme si on dictait son code de carte bleue au téléphone dans un open space. Mais la personne à qui on parle n'est pas la seule à entendre, et quelqu'un prend des notes.

Ce n'est d'ailleurs pas une maladresse isolée, puisque le comportement de « toujours autoriser » a été signalé à Anthropic dès février 2026 (ticket fermé comme doublon d'un signalement plus ancien), puis de nouveau en mai, et que des chercheurs de Check Point ont trouvé ce même fichier, avec des jetons dedans, dans des paquets npm publiés.

Ainsi, sept fois en cinq mois, j'ai trouvé chez moi un secret là où il n'avait rien à faire, la plupart du temps par hasard. Je les raconte ici au passé, sans valeur et sans nom.

Juin et juillet : le miroir, la commande, la mémoire

• Juin. Deux mots de passe d'application WordPress d'un site en production partent sur mon GitHub privé, dans le miroir de ma configuration Claude. GitGuardian me prévient alors trois jours plus tard. Les mots de passe sont changés le jour même, puis un caviardage automatique est ajouté au miroir.
• Juillet. La commande qui cherchait mes données personnelles dans un dépôt était écrite dans le fichier le plus lu du dépôt, avec la liste des termes à protéger en clair. Autrement dit, le garde-fou était la fuite.
• Juillet encore. Une fiche de mémoire de Claude contenait un jeton d'API et des identifiants. Le miroir de configuration la copiait avec le reste, car le caviardage ne couvrait pas la mémoire. Fiche expurgée à la main, et un hook avertit désormais quand un secret est écrit dans un fichier.

Septembre et octobre : les brouillons, l'export, les permissions

• Septembre. En cherchant pourquoi Claude me demandait une autorisation toutes les dix secondes, je tombe sur 84 fichiers de son dossier temporaire Windows qui portaient l'accès SFTP d'un client, en clair, dans des scripts jetables et des sorties de tâches, sur 27 sessions et cinq semaines. Je les ai purgés, puis j'ai changé la règle : les brouillons vivent désormais dans le projet, dans un dossier que je regarde.
• Septembre toujours. Puis l'export d'administration embarqué par le commit « propre », raconté plus haut.
• Octobre. La liste des permissions de mon espace de travail comptait 341 règles. 18 portaient un secret en clair, et elles étaient aussi recopiées dans 14 copies de travail. Au total, trois projets comptaient 192 occurrences dans 40 fichiers. Après la purge du 24 octobre, il reste 54 règles. Pourtant, la première proposition de faire ce ménage datait du 12 juin : 134 jours.
• Octobre, le même jour. Un mot de passe dicté dans le chat ; désormais, un hook avertit quand un secret passe dans un message.

Ce que ça donne quand l'IA lit ce qu'elle ne devrait pas, je l'ai raconté avec un README qui pirate la mémoire de toute IA qui le lit. Et lorsqu'un mot de passe est déjà parti, nettoyer le PC ne suffit pas : il faut le changer.

Les gestes

• Les identifiants vivent dans un fichier d'accès par projet (.env ou équivalent), ignoré par git, et hors du dossier synchronisé si vous le pouvez. Un petit script les lit, ainsi la commande ne les contient jamais.
• Jamais « toujours autoriser » sur une commande qui contient un secret. Purgez aussi la liste des permissions comme on purge un journal.
• Un script jetable qui contient un secret se supprime juste après usage.
• Pas de mot de passe tapé dans le chat.
• Les brouillons de l'IA vont dans un dossier connu, hors Drive, plutôt que dans un dossier temporaire du système où personne ne regarde.
• Une règle qui revient trois fois devient un automatisme. Chez moi, ce sont des hooks : ils bloquent l'écriture dans le dossier temporaire et le git init sous Drive ; ils avertissent quand un secret apparaît dans une commande, un message ou un fichier. Ils ont aussi leurs propres tests. D'ailleurs, la première version de l'un d'eux signalait le commentaire qui décrivait son propre exemple ^^

Pouvoir tout remonter si le disque meurt

Revenons enfin au 26 octobre et au document de reprise.

Il datait du 19 juin et disait : « tu ne peux pas tout perdre ». En juin, c'était vrai, puisque tout était dans Drive, historique git compris. À partir du 8 juillet, j'ai sorti les .git de Drive pour régler la cohabitation. Ça a réglé la cohabitation, mais ça a ouvert un trou de sauvegarde. Pourtant, le document n'a pas bougé, parce que personne ne relit un plan de reprise tant que tout va bien.

La première chose à comprendre, et elle vaut pour tout le monde : Drive synchronise, il ne sauvegarde pas. Ainsi, si un fichier disparaît du disque, il disparaît en ligne. De même, si un rançongiciel chiffre le disque, Drive envoie consciencieusement les fichiers chiffrés. Il reste certes une corbeille de 30 jours et un historique des versions limité. Un miroir montre fidèlement ce qu'on lui met devant, y compris la casse. Une sauvegarde, au contraire, est une copie qui ne bouge pas lorsque l'original bouge. Cybermalveillance.gouv.fr le rappelle d'ailleurs, et c'était déjà le sujet de mon guide de sauvegarde d'un site web.

Quatre couches, et ce que chacune ne contient pas

La colonne de droite est celle qui compte, car un document de reprise qui ne la remplit pas décrit ce qu'on espère, pas ce qu'on a.

À quelle condition un dépôt est à l'abri

L'historique des dépôts sans remote : emballé, chiffré, relu

Six dépôts n'ont pas de GitHub, par choix : mes dossiers administratifs, le pôle cyber, quatre sites de clients. Pour eux, le dossier local était la seule copie de l'historique.

git bundle emballe alors tout l'historique d'un dépôt dans un seul fichier :

git bundle create mon-projet.bundle --all
git bundle verify mon-projet.bundle

Ce fichier est chiffré, puis déposé dans Drive. Drive l'envoie ensuite en ligne comme n'importe quel document, et Google ne voit qu'un bloc illisible. Mon script utilise le chiffrement intégré à Node (AES-256-GCM, qui détecte aussi toute altération de l'archive). Sinon, sans script, gpg --symmetric fait le même travail.

Trois détails font la différence :

1. Relire ce qu'on a écrit. D'abord, après chiffrement, le script déchiffre l'archive réellement posée sur le disque, compare son empreinte à l'original, et repasse git bundle verify. Car une archive jamais relue est une hypothèse.
2. La clé est le maillon faible. Sans elle, les archives ne valent rien. Elle vit hors de Drive et hors du miroir de configuration, avec une copie dans un gestionnaire de mots de passe. Le piège : mon script refuse d'écraser une clé existante, mais il en fabrique une neuve si on le lui demande alors qu'elle manque. Après un sinistre, on restaure donc la clé, car une clé neuve rendrait toutes les archives existantes illisibles.
3. Une copie dans la même pièce n'est pas une copie hors site. Après tout, deux disques du même PC brûlent ensemble.

J'ai choisi une archive complète par semaine, deux versions gardées, plutôt qu'une archive mensuelle complétée d'incréments. Le poids a aussi compté dans ce choix, puisque la plus grosse fait environ 1 Go à monter par la 4G. Il n'y a pas non plus de planificateur, donc la sauvegarde part à la fin des sessions de travail sur le coffre administratif et le pôle cyber ; un tableau de bord signale ensuite une archive de plus de 8 jours.

La première vraie restauration

Le 26 octobre, j'ai restauré une archive pour de vrai, dans un dossier vide. Au total, 17 commits, le même dernier commit que le dépôt vivant, git fsck propre.

C'était toutefois la plus petite des six (0,1 Mo). La plus grosse, environ 1 Go, n'a pas encore été restaurée ; tant qu'elle ne l'a pas été, elle reste une hypothèse bien rangée.

Ce que la journée m'a appris sur les documents de reprise :

• d'abord, dater chaque affirmation d'état : « au 26 octobre », jamais « tout est sauvegardé » ;
• ensuite, lister pour chaque couche ce qu'elle ne contient pas ;
• puis faire une vraie restauration de temps en temps, et pas seulement de la plus petite archive ;
• enfin, lister ce qui n'existe qu'en un exemplaire : la clé, les codes de secours de la double authentification, le mot de passe maître du gestionnaire.

La checklist

Donc, si vous travaillez avec git dans Google Drive et une IA qui code, voici ce que je referais dès le premier jour.

Drive et git

• Aucun dossier .git dans le dossier Drive : git init --separate-git-dir=<dossier local>/<nom>.git pour tout projet neuf, à la création.
• Les copies de travail de l'IA, ses brouillons, node_modules et les gros médias hors du dossier Drive.
• En cas de fichiers « (1) » : arrêter Drive, sauvegarder, comparer, déplacer. Mais ne pas réinstaller Drive pour « réparer ».

GitHub

• Avant le premier push : auditer tout l'historique, avec un témoin positif à chaque contrôle, et ce que le prochain commit va ajouter.
• En cas de secret dans l'historique : dépôt neuf sans historique (ou réécriture), et changement du secret.
• Vérifier côté serveur après le push, plutôt que le seul message de la commande.
• Plan gratuit : pas de protection de branche sur un dépôt privé. Un hook pre-push aide, mais sans remplacer un verrou serveur.

Secrets

• Un fichier d'accès par projet, ignoré par git, et hors du dossier synchronisé si vous le pouvez. Jamais de secret dans une commande.
• Jamais « toujours autoriser » sur une commande qui contient un secret. Purger aussi la liste des permissions.
• Les brouillons de l'IA dans un dossier connu et surveillé, hors Drive.
• Pour le miroir de configuration : caviardage à la copie, liste d'exclusions, et aussi un œil sur la mémoire de l'IA.

Reprise après sinistre

• Quatre questions par projet : où sont les fichiers, où est l'historique, où est la copie hors site, quand a-t-elle été restaurée pour la dernière fois.
• Clé de chiffrement hors du poste, vérifiée. Codes de secours de la double authentification notés ailleurs que sur le PC.
• Une copie hors ligne de temps en temps : Drive synchronise aussi les catastrophes.
• Une restauration réelle par trimestre, datée.

Ce que ça dit du métier

Le sujet a l'air technique, mais les trois leçons ne le sont pas.

« Rien trouvé » ne prouve rien. Car un outil qui plante, une fois son erreur masquée, répond la même chose qu'un outil qui n'a rien trouvé : zéro. C'est arrivé deux fois dans le même audit, puis une troisième en sous-compte. Pourtant, le témoin positif ne coûte qu'une ligne.

Un état se cite avec sa date. Le 26 août, j'ai retiré le rituel de Drive en écrivant « les 12 dépôts sont externalisés ». Je ne l'avais pourtant vérifié que sur cinq. Ensuite, le 9 septembre, trois avaient encore leur historique dans Drive, puis sept le 11 octobre. Rien de grave n'a suivi, mais la phrase n'était pas prouvée le jour où je l'ai écrite.

Un plan de reprise périme en silence. On le relit donc lorsque l'architecture change, pas le jour où le disque meurt.

Le crash de 1995 m'a appris à faire des copies ; trente ans plus tard, la leçon est plutôt de vérifier que la copie se relit.

Et après

Git dans Google Drive avec une IA qui code, ça se tient, mais à condition de savoir ce que chaque couche ne fait pas. Chez moi, le montage est désormais écrit et daté (26 octobre), avec sa colonne « ne contient pas » et une première restauration réussie.

Si vous voulez outiller votre petite équipe avec une IA qui code sans y passer cinq mois, c'est ce que je fais en accompagnement IA pour les PME. Et si vous ne savez pas encore par où commencer, la page l'IA dans une petite entreprise trie par besoin.

Enfin, si vous avez le même montage et une autre panne, écrivez-moi : je compléterai la liste.

JG