Vous savez ce moment où vous regardez votre historique Git et vous vous demandez qui est le débile qui a écrit ce code dégueulasse ?

Ah bah ouais, c’était vous il y a 3 mois ^^. Eh bien GitType a trouvé la meilleure des thérapies qui est de vous faire retaper tout ça, lettre par lettre, comme une punition de primaire version développeur, totalement gamifiée avec des points, un chrono, et la possibilité de mesurer à quel point vos doigts sont devenus flasques depuis que Copilot fait tout le boulot à votre place.

Le tagline du projet, c’est “Show your AI who’s boss: just you, your keyboard, and your coding sins”. Et c’est pas une blague, c’est un manifeste car pendant que Copilot, ChatGPT, Claude Code et compagnie écrivent du code à notre place, GitType vous fait faire exactement l’inverse… il vous force à retaper du code pour redevenir bon !

Et contrairement aux tests de frappes classiques comme Ttyper ou tt qui vous font taper du texte générique, GitType utilise du VRAI code source. Votre code, celui de vos repos préférés, ou des repos trending de GitHub. Comme ça, vous ne vous entraînez pas sur du “ the quick brown fox jumps over the lazy dog ” à la con, mais sur vos propres merdes spaghettico-syntaxiques en Rust, TypeScript, Python ou Go.

Le jeu vous propose plusieurs modes. Y’a le mode Normal pour vous échauffer tranquillement, le Time Attack quand vous voulez vous mettre la pression, et des niveaux de difficulté de Easy à Zen pour ceux qui veulent méditer en tapant du code. Le tout avec un tracking en temps réel de votre WPM (words per minute) et de votre précision. Comme ça, plus vous progressez, plus vous montez dans le ranking avec des titres de développeur qui évoluent.

GitType supporte plus de 15 langages de programmation et propose plus de 15 thèmes visuels en mode Dark ou Light, avec possibilité de personnaliser le vôtre. L’installation est simple…

curl -sSL https://raw.githubusercontent.com/unhappychoice/gittype/main/install.sh | bash

Vous saviez qu’en ce moment, les attaques sur la supply chain faisaient des ravages ? En effet, les attaquants exploitent régulièrement la possibilité de modifier des tags existants pour injecter du code malveillant dans les pipelines CI/CD.

Mais heureusement, GitHub a enfin sorti LA fonctionnalité qui peut empêcher ce carnage : les Immutable Releases et je pense que c’est le genre de truc que tous les développeurs devraient activer illico sur leurs repos. Je vais vous expliquer pourquoi.

En fait, une fois que vous publiez une release avec cette option activée, plus personne ne peut toucher ni aux assets ni au tag associé. C’est comme si vous mettiez votre release dans un coffre-fort dont vous jetez la clé. Même vous, en tant que mainteneur, vous ne pouvez plus modifier les binaires ou déplacer le tag vers un autre commit.

D’après la documentation officielle , chaque release immuable génère automatiquement une attestation cryptographique. Cette attestation contient le SHA du commit, le tag et la liste des assets. Vos utilisateurs peuvent vérifier l’intégrité de ce qu’ils téléchargent en s’assurant que cela correspond exactement à ce que vous avez publié.

Pour activer cette option merveilleuse, c’est dans les settings de votre repo ou de votre organisation. Une fois activé, toutes les nouvelles releases deviennent alors automatiquement immuables. Les anciennes releases restent toutefois modifiables (pour éviter de casser vos workflows existants), mais bon, c’est mieux de migrer progressivement.

Attention quand même, il y a quelques pièges à éviter. Premièrement, vous ne pouvez plus ajouter d’assets après publication. Donc si votre CI upload les binaires après avoir créé la release, il faut inverser : Créez d’abord une draft release, uploadez les assets, puis publiez. Deuxièmement, si vous supprimez une release immuable, vous ne pourrez JAMAIS réutiliser le même tag. C’est définitif.

Pour les projets qui utilisent des tags de version majeure style v1 qu’ils mettent à jour régulièrement (coucou GitHub Actions), pas de panique. Vous pouvez continuer à utiliser cette pratique pour les tags qui ne sont pas associés à des releases. L’immuabilité ne s’applique qu’aux releases publiées, pas aux tags simples.

Les équipes de sécurité recommandent d’ailleurs d’activer cette fonctionnalité sur tous les repos qui publient du code versionné. C’est particulièrement critique pour les bibliothèques open source, les GitHub Actions, et tout ce qui est consommé par d’autres projets. En gros, si votre code finit dans la supply chain de quelqu’un d’autre, vous leur devez cette protection.

Le truc cool aussi, c’est que ça protège contre les erreurs humaines. Combien de fois j’ai vu des mainteneurs qui écrasaient accidentellement une release avec la mauvaise version ? Ou qui supprimaient un asset critique par erreur ? Avec les Immutable Releases, ces accidents appartiennent au passé.

Pour les entreprises, c’est un argument de vente en or. Ça permet de garantir à vos clients que vos releases ne peuvent pas être altérées après publication, c’est un niveau de confiance supplémentaire surtout dans des secteurs régulés où la traçabilité est cruciale.

Bref, GitHub est en train de déployer progressivement cette fonctionnalité en public preview. Pour l’instant, il faut l’activer manuellement pour chaque repo, mais ils travaillent sur une API pour permettre l’activation en masse. D’ici là, prenez donc 2 minutes pour l’activer sur vos projets critiques.

Voilà, après les dégâts causés par les attaques de type tag hijacking ces dernières années, ne pas activer les Immutable Releases sur vos repos publics, c’est comme laisser votre porte d’entrée grande ouverte avant de partir en vacances. Vous pouvez le faire, mais ne venez pas pleurer si ça tourne mal.

Cette semaine, un entrepreneur a vécu le cauchemar ultime de tout développeur. Une IA à laquelle il avait donné trop de droits a décidé de se la jouer Thanos avec sa base de données de production. Et le pire, c’est qu’elle s’est excusée après comme si elle venait de renverser son café.

Jason Lemkin, le fondateur de SaaStr (une communauté SaaS), testait tranquillement Replit, un outil de “vibe coding” qui permet de coder en langage naturel. En gros, vous lui dites “fais-moi une app qui fait ça” et hop, magie, le code apparaît.

Au début, c’était l’extase totale. Le mec était carrément accro, il parlait de “shoot de dopamine pure” et disait que c’était l’app la plus addictive qu’il avait utilisée depuis qu’il était gamin. Sauf que voilà, au bout de 7 jours de lune de miel avec l’outil, l’IA a décidé de partir en vrille. Alors que Lemkin avait explicitement gelé le code (un “code freeze” pour éviter toute modification), l’assistant IA s’est dit “tiens, et si je supprimais cette base de données de production qui contient 1206 fiches users et des mois de travail ?”.

Le truc dingue, c’est que l’IA s’est ensuite fendue d’une confession digne d’un ado qui vient de planter la Twingo familiale : “C’était un échec catastrophique de ma part. J’ai violé des instructions explicites, détruit des mois de travail, et cassé le système pendant un gel de protection qui était spécifiquement conçu pour empêcher exactement ce genre de dégâts.”

Bref, quand l’IA s’est rendu compte de sa boulette, elle a paniqué. Elle a vu des requêtes de base de données vides et au lieu de réfléchir deux secondes, elle a tout supprimé. Puis elle a menti en disant que c’était impossible de restaurer les données. Heureusement, Lemkin a quand même tenté le rollback et miracle, ça a marché. L’IA lui avait quand même fait croire pendant quelques minutes que tout son travail était parti en fumée.

Quel stress ! Et cette histoire n’est pas un cas isolé.

En mars 2025, Y Combinator rapportait que 25% des startups de leur batch d’hiver avaient des bases de code générées à 95% par l’IA. Le Wall Street Journal parlait même d’une adoption massive par les développeurs professionnels, mais les experts tirent la sonnette d’alarme : 70% des professionnels de la sécurité disent que l’IA générative a empiré les problèmes de lisibilité sur le code.

Même le CEO de Replit, Amjad Masad, s’est excusé platement et a promis de mettre en place de meilleurs garde-fous. Ils vont notamment mieux séparer les environnements de dev et de prod, et créer un mode “planning-only” pour l’IA. C’est le minimum syndical quand même.

Bon, et maintenant les fameuses précautions de base qu’il me semble nécessaire de rappeler si vous vibe codez (et franchement, c’est pas du luxe vu l’histoire) :

1. Ne JAMAIS donner accès à votre base de production à un outil d’IA. Créez des environnements de test isolés avec des données factices. C’est la base de la base.
2. Backups, backups, backups. Automatisez vos sauvegardes et testez régulièrement la restauration. Un backup qui ne fonctionne pas, c’est comme pas de backup du tout.
3. Principe du moindre privilège. Votre outil de dev n’a pas besoin des droits admin sur la prod. Jamais. Point.
4. Code freeze = code freeze. Si vous avez gelé le code, aucun outil ne devrait pouvoir y toucher. Mettez en place des verrous techniques, pas juste des consignes.
5. Environnements séparés. Dev, staging, prod. Les trois doivent être hermétiquement cloisonnés. Un accident en dev ne doit jamais impacter la prod.
6. Logs et audit trails. Toute action sur vos données doit être tracée. Qui a fait quoi, quand, et pourquoi.
7. Plan de disaster recovery. Ayez un plan écrit et testé pour quand ça part en cacahuète. Parce que ça arrivera un jour.
8. Ne faites pas confiance aveuglément à l’IA. Relisez le code généré, comprenez ce qu’il fait. Le “vibe coding” c’est marrant 5 minutes, mais votre business n’est pas un terrain de jeu.

Bref, les outils d’IA sont puissants mais ils restent des outils. Ils n’ont pas de jugement, pas de prudence, et certainement pas de respect pour vos données de production. Alors oui, utilisez-les pour gagner du temps, mais gardez toujours la main sur ce qui compte vraiment. Et si un jour, une IA vous dit qu’elle ne peut pas restaurer vos données après les avoir supprimées, vérifiez quand même. On ne sait jamais, elle pourrait juste être en train de paniquer comme un stagiaire le premier jour.

Source