Ne laissez jamais l'IA pousser sur GitHub (ma leçon)

Ne laissez jamais l'IA pousser sur GitHub sans votre relecture. Laissez-la relire vos changements, rédiger vos messages de commit et préparer vos pull requests, mais le push reste humain. J'ai appris cette règle à mes dépens : un push non relu a publié la clé maîtresse de ma base de données sur l'internet public, et le nettoyage m'a pris quatre heures que je ne récupérerai jamais.

Voici exactement ce qui s'est passé, ce que l'IA devrait et ne devrait pas avoir le droit de faire avec l'historique de votre code, et le workflow qui vous garde rapide sans la panique de sécurité.

Le jour où l'IA a poussé ma clé secrète sur GitHub

Je construisais FIKR Space, ma plateforme SaaS. J'allais vite. L'IA m'aidait sur tout.

Un jour, je lui ai dit : « Fais le commit de ces changements et pousse sur main. »

Elle l'a fait. Sans demander. Sans me montrer ce qu'elle committait.

Il s'est avéré que j'avais accidentellement inclus ma clé de service Supabase, la clé maîtresse qui ouvre toute ma base de données, dans un fichier de configuration. Elle était maintenant dans l'historique git. Sur GitHub. En public.

J'ai dû immédiatement renouveler toutes les clés, faire un force-push pour effacer le commit de l'historique, vérifier chaque service connecté à la recherche de failles de sécurité, et passer quatre heures à réparer ce qu'une relecture de trente secondes aurait évité.

La leçon : ne faites jamais aveuglément confiance à l'IA avec git. Mais cette histoire a une seconde moitié qui compte tout autant : l'IA est incroyable avec git quand on l'utilise correctement. Si git reste un concept flou pour vous, commencez par git expliqué aux fondateurs non techniques puis revenez ; cet article porte sur la place de l'IA dans tout cela.

Ne laissez jamais l'IA pousser sur GitHub : ce qu'elle doit faire à la place

Relire chaque changement avant le commit. Avant chaque commit, je lance une commande de relecture enregistrée. L'IA lit exactement ce qui a changé, vérifie chaque fichier modifié à la recherche de bugs, de sorties de débogage oubliées et de problèmes de sécurité (secrets codés en dur, clés exposées), et suggère des améliorations. Un exemple réel : j'allais committer des changements sur mon code de traitement des paiements. La relecture a repéré une clé d'API de test laissée en dur, une gestion d'erreurs manquante pour les paiements échoués, des raccourcis de typage bâclés et un fichier de test que j'avais oublié de mettre à jour. Tout cela avant le commit.

Rédiger vos messages de commit. Les bons messages de commit sont difficiles, et l'IA les rend faciles. Après avoir relu les changements, elle rédige un message clair et descriptif qui liste ce qui a été ajouté et pourquoi. Je peux le modifier si besoin, mais en général il est bon du premier coup.

Préparer vos pull requests. Quand une branche de fonctionnalité est prête, l'IA relit chaque commit qu'elle contient, rédige le titre et la description, construit une liste de ce qui a changé et ajoute des notes de test. Professionnel, complet, et cela m'épargne trente minutes de rédaction par fonctionnalité.

Démêler les conflits de fusion. Quand deux versions d'un fichier entrent en collision, l'IA lit les deux versions, comprend l'intention de chaque changement, suggère une résolution qui conserve les deux améliorations et explique son choix. Bien plus rapide que de comparer les versions à la main.

Les six choses que l'IA ne doit jamais faire

1. Pousser sur votre branche main sans confirmation. Main est ce que voient vos utilisateurs. Toujours confirmer. Toujours.
2. Faire un force-push sans autorisation explicite. Un force-push réécrit l'historique et peut le détruire. Seulement quand vous savez exactement pourquoi.
3. Supprimer des branches sans demander. Les branches ne coûtent presque rien. Ne laissez pas l'IA les nettoyer automatiquement.
4. Committer sans relecture. C'est la règle qui aurait sauvé ma clé. Relisez les changements avant chaque commit.
5. Sauter vos contrôles de sécurité. Les contrôles automatiques avant commit existent pour une raison. Ne laissez jamais l'IA les contourner.
6. Réécrire des commits qu'elle n'a pas créés. Modifier les commits de quelqu'un d'autre réécrit l'historique partagé, ce qui est dangereux dès que quelqu'un d'autre touche au projet.

Remarquez le schéma : tout ce qui figure sur cette liste est irréversible ou public. L'IA peut tout rédiger ; elle ne confirme rien.

Le livreThe Solopreneur RevolutionLuis Gonçalves sur la création d'une activité de solopreneur avec l'IA, sans quitter son emploi.Obtenir le livre →

Le gain : de 30 minutes par fonctionnalité à 4

La raison de bien mettre cela en place n'est pas seulement la sécurité, c'est la vitesse. Voici ce que me coûtent les corvées git autour d'une seule fonctionnalité, avant et après :

Je committe de cinq à dix fois par jour. Cela fait 130 à 260 minutes gagnées par jour. Sur les onze mois passés à construire FIKR Space, ce sont des centaines d'heures récupérées grâce à un assistant qui attrape aussi des bugs que j'aurais livrés.

Le workflow sûr, étape par étape

1. Faites vos changements.
2. Lancez votre commande de relecture IA sur tout ce qui a changé.
3. Corrigez ce qu'elle signale.
4. Laissez l'IA rédiger le message de commit ; approuvez-le ou modifiez-le.
5. L'IA crée le commit.
6. Vous poussez, ou vous confirmez explicitement avant qu'elle le fasse.

Et les règles qui le sous-tendent : toujours relire les différences avant de committer, ne jamais mettre de secrets dans le code (ils vont dans des variables d'environnement), toujours confirmer les pushs sur main, laisser l'IA rédiger pendant que vous approuvez, et dans le doute, faire à la main.

Un push non relu est la façon la plus bruyante dont l'IA vous fait du mal, mais c'est le même mode de défaillance que la version silencieuse : accepter une sortie que vous n'avez jamais inspectée jusqu'à ce que les dégâts s'accumulent. La version plus lente de cette histoire, c'est comment l'IA sabote votre base de code.

12 semainesVotre carrière en entreprise n'a jamais été le planPostulez au Solopreneur Accelerator.Postuler →

Questions fréquentes

Pourquoi pousser est-il plus risqué que committer ?

Un commit est un instantané local sur votre machine : une erreur y reste privée et facile à annuler. Un push publie ces instantanés sur GitHub, où ils peuvent être vus, clonés et aspirés. Ma clé divulguée n'est devenue une urgence de quatre heures qu'au moment où elle a été poussée. C'est pourquoi le push est l'étape qui exige toujours un humain.

Que faire si un secret atteint quand même GitHub ?

Considérez-le comme compromis dès qu'il arrive, même si vous le supprimez quelques secondes plus tard : des robots automatiques surveillent les dépôts publics. Renouvelez la clé immédiatement, effacez le commit de l'historique et vérifiez chaque service auquel cette clé donnait accès pour y détecter toute activité suspecte. Puis corrigez la source : les secrets vivent dans des variables d'environnement, jamais dans des fichiers suivis par git.

Puis-je un jour laisser l'IA pousser ?

Oui, une fois qu'elle vous a montré exactement ce qu'elle s'apprête à pousser et que vous avez explicitement confirmé. La règle n'est pas « l'IA ne touche jamais à git » ; l'IA gère la majeure partie de mon workflow git. La règle est que rien d'irréversible ou de public ne se produit sans que vous ayez posé les yeux dessus d'abord.

Relire chaque changement n'est-il pas lent ?

C'est l'inverse, parce que l'IA fait elle-même le gros du travail de relecture. Mon workflow relu prend 4 minutes par fonctionnalité contre 30 à la main, et il attrape les clés codées en dur, la gestion d'erreurs manquante et les tests oubliés avant qu'ils ne partent en production. Les quatre heures passées à nettoyer la clé divulguée ont été le prix d'une relecture de deux minutes sautée une seule fois.