Skip to main content
gitai-coding-assistantsprompt-engineering

Comment je restreins l'IA dans Git

La discussion s'est résumée à une idée simple : un simple prompt système ne suffit pas pour la sécurité Git. Il faut des restrictions en lecture seule par défaut, une confirmation explicite avant les commits et pushs, et des règles claires de branches et PR. Sinon, l’automatisation IA en développement corrompt facilement le travail inachevé.

Contexte technique

Je ne ferais pas du tout confiance à un seul prompt système quand il s’agit de Git. Lorsque j’intègre l’intelligence artificielle dans le processus de développement, ma première règle est ennuyeuse mais elle sauve les nerfs : toute action autre que la lecture seule est interdite, à moins que je ne la demande explicitement.

La raison est basique. Claude comme Codex, dans des sessions parallèles, peuvent consciencieusement écraser des modifications en cours parce que pour eux, le répertoire de travail local n’est qu’un énième état du projet. Je l’ai vu plus d’une fois, et c’est là qu’un beau prompt s’arrête et que la discipline d’ingénierie commence.

Je code généralement quelques règles directement dans les instructions de l’agent : pas de commit, push, rebase, suppression de branche ni checkout avec effets secondaires sans confirmation ; avant toute modification, montrer ce qui sera exactement affecté ; après la génération de code, lancer d’abord les tests ou la compilation. Si le projet est lourd, j’interdis en plus les commits sans approbation, car il est souvent plus rapide de traiter le code IA lorsque les modifications restent non commitées.

De la pratique en équipe, j’apprécie aussi des choses plus terre-à-terre : un format unifié de branche de fonctionnalité avec un identifiant de tâche, un lien vers la PR dans le tracker, une description courte en langage humain de la PR, et une notification dans Slack ou Telegram pour la revue de code. Ce n’est pas de la bureaucratie, c’est pour éviter que l’IA ne transforme l’historique Git en un dépotoir sans contexte.

Et oui, si un contrôle réel est nécessaire, je ne me limiterais pas aux prompts. Des couches de sécurité externes pour le CLI qui exigent une confirmation ou bloquent les commandes Git dangereuses sont plus fiables qu’un simple « ne fais jamais ça » dans un prompt système.

Ce que cela change pour les entreprises et l’automatisation

Ici, les équipes où plusieurs personnes et plusieurs sessions IA fouillent le même dépôt en tireront profit. Celles qui courent après la vitesse et permettent à l’agent de commiter tout ce qui passe y perdront : au début, cela semble rapide, puis on passe une demi-journée à chercher qui a cassé la branche et pourquoi des bouts de code ont disparu.

Pour l’implémentation de l’IA, je vois exactement trois conséquences. Premièrement, un cycle légèrement plus lent, mais moins d’écrasements accidentels. Deuxièmement, des revues plus propres et une responsabilité plus claire sur les PR. Troisièmement, il est plus facile de passer à l’échelle l’automatisation avec l’IA entre les équipes, car les règles sont lisibles aussi bien par les humains que par les agents.

Chez Nahornyi AI Lab, nous décortiquons précisément ces situations : où l’agent peut avoir de la liberté et où il a besoin d’une laisse courte. Si votre IA écrit déjà du code mais que le processus commence à casser les branches, les revues et les délais, nous pouvons examiner sereinement votre flux de travail et concevoir une automatisation IA qui accélère le développement au lieu de créer de nouvelles catastrophes.

Précédemment, nous avons examiné MicroMorph, un agent Python autonome capable de modifier son propre code à l’exécution, ce qui présente des risques importants pour la sécurité et la stabilité. Ce cas montre clairement pourquoi les invites système limitant ce comportement deviennent essentielles.

Partager cet article