🤖 Développement Agentique – Part 2

Choisir l’agent selon la tâche

Workflow global

Les anti-patterns à éviter

Les rules : la constitution du projet

Les rules disent à l’agent comment travailler : conventions, architecture, commandes de test, contraintes SQL, interdits, style, sécurité, format de sortie. Sans rules, l’agent improvise. Avec rules, il travaille dans un cadre.

Project rules:
- Use small surgical patches.
- Do not rewrite full files unless explicitly approved.
- Do not add indexes on large text fields.
- Keep code comments in English.
- Prefer Django management commands for diagnostics.
- Add dry-run, verbose mode and counters for long operations.
- Run checks or explain why they cannot be run.
- Always summarize changed files and risks.

La boucle Cursor sérieuse

Connecter des outils : puissance et danger

MCP et les outils externes peuvent rendre l’agent plus utile : documentation, ticketing, recherche, tests, outils internes. Mais chaque capacité ajoutée augmente aussi le risque. On connecte uniquement ce qui est nécessaire, et jamais des secrets ou un accès production sans sandbox strict.

Classer les commandes avant exécution

Before running commands, classify them as:
- read_only
- local_test
- environment_change
- data_mutation
- destructive

Do not run data_mutation or destructive commands without explicit approval.

Cas d’usage Django/Python

Pack prompts terminal

Analyze first. Do not edit files.
Find the minimal set of files involved.
Explain the execution path and likely defect.
Propose one small patch.
List commands that would prove the fix.

Apply only the approved patch.
Do not reformat unrelated code.
Do not rename public APIs.
After editing, run the smallest relevant check.
If a check fails, report the exact error and patch only the cause.

Create a Django management command with:
- argparse options
- dry-run mode
- verbose mode
- progress counters
- structured final summary
- no interactive shell dependency
- safe error handling
- production-oriented logging

Template d’issue exploitable par agent

Title: Add validation report to migration safety command

Goal:
Create a validation report for the migration safety workflow.

Scope:
- management command only
- no model changes
- no UI changes
- no production database mutation

Acceptance criteria:
- command supports --dry-run
- command prints counters
- command exits non-zero on validation failure
- unit tests cover success and failure cases

Relevant files:
- app/management/commands/migrate_safe.py
- app/services/migration_validation.py
- tests/test_migration_validation.py

Do not:
- rewrite unrelated files
- change existing public behavior
- add dependencies

Proof:
Run the relevant tests and include output summary.

Relire une PR produite par agent

Règles de gouvernance

• L’agent travaille sur branche dédiée.
• L’agent ne merge jamais sa propre PR.
• La CI doit passer avant review.
• Les changements sécurité exigent un reviewer humain compétent.
• Les instructions repo doivent être maintenues comme de la vraie documentation.
• Une PR agent doit contenir résumé, tests, risques et limites.
• Rejeter une PR agent n’est pas un échec : c’est un mécanisme de qualité.

Découper pour le parallèle

Good task format:
- objective
- repository area
- files allowed
- files forbidden
- output expected
- commands allowed
- acceptance criteria
- risk level

Review de résultats parallèles

Très bons cas d’usage

Structure recommandée

# Agent Instructions

## Project mission
Explain what the project does in five lines.

## Architecture map
List important apps, services, commands and templates.

## Coding rules
Define naming, style, patch scope and forbidden patterns.

## Database rules
Define migration policy, index policy and data safety rules.

## Test commands
List exact commands for unit tests, checks and migrations.

## Security boundaries
List files, data and commands that agents must not access or modify.

## Review output
Every answer must include changed files, risks, tests and next steps.

Ni trop peu, ni trop de contexte

Un agent n’a pas besoin de toute l’histoire de l’entreprise. Il a besoin du plus petit contexte fiable pour la zone ciblée. Trop peu : hallucination. Trop : dilution et contradictions.

Doctrine Django à donner aux agents

Django project doctrine:
- Prefer management commands for repeatable diagnostics.
- Avoid ad-hoc shell troubleshooting as the final solution.
- Include dry-run mode for commands that inspect or mutate data.
- Never create indexes on very large text fields without explicit approval.
- Keep deduplication rules in application code when required by design.
- Add admin list displays, filters and actions only when operationally useful.
- Make migrations reviewable and reversible when possible.
- Add logs, counters and final summaries for long-running operations.
- Do not hide exceptions silently.
- Keep patches surgical and testable.

Prompts de diagnostic

Analyze the bug without editing files.
Return:
1. likely root cause
2. files involved
3. execution path
4. evidence from code
5. smallest safe fix
6. tests needed
Do not modify anything yet.

Inspect this Django management command.
Find:
- missing error handling
- missing counters
- unsafe data mutation
- missing dry-run behavior
- missing final summary
- unclear logging
Return a prioritized patch plan.

Prompts de patch

Apply Patch 1 only.
Scope:
- create the service function
- do not modify admin or templates
- do not change models
- keep the public API stable
After patch:
- show changed files
- explain risks
- list tests to run

Add observability to this command.
Requirements:
- verbose mode
- debug mode
- progress counters
- final JSON-like summary
- clear non-zero exit on failure
- no interactive input

Prompts de review

Review this diff as a strict senior engineer.
Focus on:
- hidden behavior changes
- missing tests
- security risk
- performance regression
- database risk
- maintainability
Return blockers, warnings and optional improvements.

Compare the patch against the original plan.
List:
1. requirements satisfied
2. requirements missing
3. unrequested changes
4. risky assumptions
5. whether this can be merged

Protocole de coordination

Éviter les conflits

• Une branche ou worktree par agent.
• Ownership clair des fichiers.
• Pas d’édition concurrente du même fichier sans plan.
• Commits petits et cherry-pickables.
• Branche d’intégration humaine.
• Tests après chaque patch accepté.
• Expériences jetables plutôt que rewrite spéculatif.

Safe parallel split:
agent-a: investigate failing migration
agent-b: write test cases
agent-c: document current behavior
agent-d: propose rollback plan
human: select one patch path

Le pattern “conseil d’agents”

Pour une décision d’architecture difficile, utiliser plusieurs agents comme conseillers, pas comme implémenteurs. Chaque agent propose une option avec hypothèses, risques, étapes et rollback. Ensuite seulement, un humain choisit.

Ask three agents independently:
- propose an architecture
- list assumptions
- list risks
- estimate implementation steps
- identify rollback strategy

Then ask a reviewer agent:
- compare proposals
- find common ground
- find hidden risks
- recommend the smallest safe first patch

Commandes de vérification Django

python manage.py check
python manage.py makemigrations --check --dry-run
python manage.py showmigrations
python manage.py test
python manage.py test app_name.tests.test_specific_case
python manage.py migrate --plan

Checks complémentaires

python -m compileall .
python -m pytest
python -m ruff check .
python -m mypy .
python manage.py collectstatic --dry-run --noinput

Discipline rollback

Un patch opérationnel doit parler

Pour les crons, analyzers, repair tools ou pipelines de réplication, un patch doit produire des faits : compteurs, durée, erreurs, warnings, skip, dry-run, statut final.

Final report format:
status: success | warning | failed
changed_files: N
records_scanned: N
records_changed: N
records_skipped: N
errors: N
warnings: N
duration_seconds: N
dry_run: true | false
next_action: text

Messages de commit

good:
feat(migrations): add dry-run validation report
fix(admin): preserve filter state after action
refactor(search): split parser service from command

bad:
agent changes
update files
fix stuff
big refactor

Le fait que l’agent ait aidé est secondaire. Ce qui compte : ce qui change, pourquoi, avec quelle preuve.

Checklist de PR

PR checklist:
- scope matches issue
- no unrequested files changed
- no secrets or sensitive data added
- migrations reviewed
- tests or checks included
- rollback documented
- performance impact considered
- logs and counters added when operational
- documentation updated if behavior changed
- human reviewer accepts accountability

Lire un diff agentique

• Commencer par la liste des fichiers.
• Identifier les changements non demandés.
• Vérifier les signatures publiques.
• Chercher les changements silencieux de comportement.
• Repérer les except trop larges.
• Contrôler la qualité des tests générés.
• Relire les migrations ligne par ligne.
• Vérifier que les logs ne sortent aucune donnée sensible.

Zones interdites

Agents must not access or modify:
- production credentials
- private keys
- payment secrets
- customer personal data
- production database dumps
- deployment tokens
- infrastructure state files
- legal documents unless explicitly approved
- license keys
- authentication bypass logic

Checklist secure coding

• Authentification préservée.
• Autorisation explicite et testée.
• Pas de SQL brut depuis entrée utilisateur.
• Pas de désérialisation dangereuse.
• Pas de CORS large sans justification.
• Pas de debug ou stack trace exposé.
• Pas de secret dans logs, erreurs, commentaires ou tests.
• Pas de dépendance non relue.
• Pas d’export de données sans contrôle d’accès.
• Pas d’exception silencieuse masquant une faille.

Traçabilité

Une tâche agentique doit laisser une trace normale d’ingénierie : issue, plan, branche, commits, PR, CI, reviewer, décision. En environnement client ou réglementé, noter l’outil utilisé et l’humain qui a validé.

Audit fields:
- issue_id
- agent_tool
- agent_session_id
- branch_name
- human_reviewer
- risk_class
- tests_run
- CI_status
- merge_decision
- rollback_note

Mesurer la réalité, pas le buzz

Modèle de maturité

Former l’équipe

• Apprendre la structure de prompt : scope, contraintes, critères.
• Apprendre la lecture de diff IA.
• Apprendre les limites sécurité.
• Apprendre la validation par tests.
• Apprendre quand ne pas utiliser d’agent.
• Construire une bibliothèque de prompts approuvés.
• Analyser les échecs d’agents et améliorer les rules.

Weekly team ritual:
- one useful prompt added
- one bad agent output analyzed
- one rule improved
- one metric reviewed
- one workflow simplified

Standard management command

Every production management command should include:
- --dry-run
- --limit
- --verbose
- --debug
- --export-json or --export-excel when useful
- clear start banner
- progress counters
- final summary
- non-zero exit on failure
- exception boundaries
- no hidden interactive dependency

Prompts migration safety

Analyze this Django migration for MariaDB and PostgreSQL safety.
Check:
- long index risk
- table lock risk
- data migration reversibility
- field type compatibility
- transaction behavior
- expected runtime on large tables
Return a risk table and safer alternatives.

Create a migration resolver plan.
Do not edit files yet.
The plan must include:
- original migration backup
- corrected migration output
- remaining diff to apply
- model-level resolver proposal
- verification command
- rollback strategy

Admin généré par agent

Un agent peut produire un admin Django vite, mais il oublie souvent les filtres utiles, les catégories lisibles, les compteurs, les permissions et l’optimisation queryset. Il faut expliciter le standard attendu.

Build a Django admin dashboard with:
- readable list_display
- useful list_filter
- search_fields
- date_hierarchy when relevant
- readonly_fields for audit data
- safe admin actions only
- no heavy query in list display
- optimized queryset with select_related where useful

Politique de maintenance

Les outils évoluent vite : capacités, prix, modèles, intégrations IDE, sécurité entreprise, limits et fonctionnalités cloud. Un guide public doit être revu régulièrement.

Quarterly update checklist:
- verify official docs URLs
- update tool capability table
- update enterprise/security options
- refresh prompt examples
- add new agent workflows
- remove deprecated commands
- test modal UI after edits