L'IA écrit mon code, je garde les clés

Depuis plusieurs semaines, je n'écris plus de code. Sur mes sites et mes bundles, c'est une IA qui écrit tout : les fonctionnalités, les tests, les corrections, la documentation. Je décris, je relis, je décide.

Je me présente aussi comme un développeur orienté sécurité. La question arrive vite : « Tu fais de la sécurité, et tu confies tout à une IA ? »

Oui. Mais pas les clés.

Le risque n'est pas qu'elle écrive du code

Une IA qui écrit du code se trompe, comme un développeur. Elle l'a fait cette semaine : un réglage de Sentinelle, mon bundle de sécurité, ne s'appliquait jamais, alors que ses tests passaient (je raconte le bug ici). Ce genre d'erreur se voit, se corrige et s'annule : tout est dans Git, relisible, daté.

Le vrai risque, c'est autre chose : qu'elle ait accès à ce qui ne s'annule pas. Le serveur, les bases de données, les clés de paiement, les comptes. C'est là que je trace la ligne.

Qui peut faire quoi

L'IA travaille dans un environnement à part, jetable, qui n'est pas mon serveur. Elle y écrit le code, y lance les tests, et envoie le résultat sur GitHub. Elle n'a aucun accès au serveur. Aucun mot de passe, aucune clé d'API ne passe par nos échanges : quand une clé doit être posée, elle me guide pas à pas, et c'est moi qui la tape, directement sur le serveur.

Le serveur lit le code sur GitHub, mais ne peut rien y écrire : sa clé d'accès est en lecture seule. Il fait seul le travail mécanique, celui qui ne demande aucun jugement.

Moi, je garde les clés : les comptes, les secrets de production, l'accès au serveur. Et je tranche quand il faut trancher.

La règle tient en une phrase : ce qui est mécanique va au serveur, ce qui demande du jugement va à l'IA, ce qui engage reste à moi.

Ce qui tourne déjà

• Les tests avant chaque envoi. L'IA les lance dans sa copie jetable. Un changement qui casse un test ne part pas.
• La ronde de nuit du serveur. Chaque base de données est sauvegardée, et la sauvegarde est relue pour vérifier qu'elle est exploitable. Tout ce qui tourne est analysé à la recherche de failles connues. Un site dont PHP a un correctif de retard est reconstruit, et tout est reconstruit à neuf chaque semaine.
• Sentinelle dans l'application. Elle bloque les robots qui cherchent des secrets, et ne m'écrit à la minute que si quelque chose est vraiment sorti.

Ce qui ne tourne pas encore

Je préfère le dire plutôt que de le laisser croire.

• Les sauvegardes hors du serveur. Aujourd'hui, les sauvegardes restent sur le serveur : elles protègent d'une mauvaise commande, pas de la perte du serveur. La suite est en cours : une copie chiffrée chez un second fournisseur, avec une durée de conservation que personne ne peut raccourcir, pas même moi, et une copie de tous les dépôts de code ailleurs que sur GitHub. Avec un test de restauration chaque mois.
• Le retour arrière automatique. Si un déploiement casse un site, la version précédente doit revenir seule. C'est prêt, mais pas encore essayé en production. Tant que ce n'est pas fait, je ne le compte pas.
• Les mises à jour de nuit. Uplift prépare les montées de PHP et de Symfony dans une copie à part et un conteneur jetable, les teste, puis attend ma validation. Le bundle est publié ; son branchement sur la ronde de nuit attend la prochaine mise en production.
• La double authentification partout, par application et pas par SMS, avec des codes de secours imprimés. C'est vingt minutes de mon temps, et c'est sur ma liste.

Pourquoi je l'écris

Parce que « je fais attention » ne veut rien dire. Une chaîne qu'on peut décrire, avec ce qui est fait et ce qui manque, se vérifie. J'ai mis cette chaîne sur une page à part, Comment je protège mes sites, que je mettrai à jour à chaque maillon ajouté.

Et parce que la question « tu confies tout à une IA ? » est la bonne question. La réponse n'est ni « oui, elle est très forte » ni « non, jamais ». C'est : qu'est-ce qu'elle peut toucher, et qu'est-ce qui se passe quand elle se trompe ?