AymericDev← Retour à l’accueilEnglish ↗

Du besoin à la mise en production

Ma façon de travailler

Je pars de votre besoin, j’expérimente et je construis par étapes. En IA comme en développement web, je cherche à rendre les choix compréhensibles, les progrès visibles et les résultats vérifiables.

01 / La collaboration

Avancer ensemble, par étapes.

  1. Comprendre le besoin

    Nous clarifions les objectifs, les usages, les contraintes et les critères de réussite. Je découpe le besoin en priorités concrètes pour définir une première étape utile.

  2. Concevoir et expérimenter

    Je choisis une solution adaptée au contexte et je teste les hypothèses avec un prototype lorsque c’est nécessaire. Pour un projet d’IA, cela passe aussi par l’examen des données et des critères d’évaluation.

  3. Développer par étapes

    Je développe par petits incréments, avec des tests adaptés aux comportements attendus et aux risques. Des points réguliers permettent de recueillir vos retours et d’ajuster la suite.

  4. Livrer et accompagner

    Je prépare le déploiement, la documentation utile et la prise en main. Les retours d’usage guident ensuite les corrections et les prochaines évolutions, selon le suivi convenu.

02 / La méthode de développement

Des repères issus de l’Extreme Programming.

Mon approche s’inspire de l’Extreme Programming (XP) : des itérations courtes, des échanges fréquents et une attention continue à la qualité du logiciel. Chaque étape doit apporter un résultat que l’on peut examiner et améliorer.

  • Des besoins concrets et de petites livraisons pour obtenir rapidement du feedback.
  • Des tests pour préciser le comportement attendu et sécuriser les évolutions.
  • Un code simple, amélioré progressivement par le refactoring et intégré fréquemment.
Schéma de l’Extreme Programming : besoins, petite itération, tests d’abord, code simple, intégration continue, livraison et feedback, puis retour aux besoins.Ouvrir le schéma en grand
Extreme Programming — une boucle d’apprentissage et de livraison.Schéma en français.

Lecture du schéma

La boucle relie six étapes, du besoin au retour utilisateur. À l’intérieur d’une itération, le cycle test → code → refactoring permet de vérifier puis d’améliorer la solution. Communication, simplicité, feedback, courage et respect orientent ce travail.

J’adapte ces pratiques à la mission et à l’équipe. Le schéma présente aussi les valeurs et les pratiques collectives de XP, comme le pair programming ; leur mise en place dépend du contexte de collaboration.

Les pratiques de l’Extreme Programming

03 / Le suivi des versions

Git, avec des branches courtes.

Pour suivre les évolutions du code, je privilégie un workflow Trunk-Based Development avec Git : une branche principale de référence, main, et des branches de travail courtes, réintégrées fréquemment.

  • Un changement limité, isolé depuis main, avec de petits commits qui racontent une évolution précise.
  • Une pull request pour présenter le changement, lancer les vérifications automatiques (CI) et faciliter la relecture.
  • Une fusion rapide après validation, avec l’objectif de garder main stable et déployable.
Schéma Git en Trunk-Based Development : une branche feature/login part de main, reçoit quelques commits et revient dans main après une pull request, les contrôles et la relecture.Ouvrir le schéma en grand
Git — le parcours d’un changement jusqu’à la branche principale.Schéma en français.

Lecture du schéma

Créer une branche depuis main → faire de petits commits → les publier (push) → ouvrir une pull request → vérifier avec la CI et la relecture → fusionner rapidement. Les branches restent courtes, les commits ciblés et main déployable.

Ce rythme garde les changements faciles à relire et limite les écarts entre les branches. Les conventions de nommage et les règles de validation sont définies en fonction du projet.

Le principe des branches courtes

04 / Le travail avec Codex

Développer avec Codex, garder la maîtrise.

Je confie à Codex une large part de la production du code, tout en pilotant les objectifs, l’architecture et les choix techniques importants. Je définis le cadre de travail, examine les résultats et reste responsable de la qualité du logiciel livré.

  • Le dépôt sert de mémoire au projet : code, README, documentation d’architecture, consignes AGENTS.md, décisions et état d’avancement restent accessibles d’une session à l’autre.
  • Je découpe le travail en petites tâches avec un résultat observable et j’organise des sessions ciblées par fonctionnalité.
  • Avant un changement structurant, Codex propose un plan que je valide. Il peut ensuite exécuter la tâche de façon autonome dans le périmètre convenu.
  • Je demande des preuves adaptées au changement : tests réellement exécutés, résultats de CI ou démonstration, accompagnés d’une explication de ce qui a changé.
Schéma du travail avec Codex en neuf étapes, de la vision produit au merge, avec validation humaine du plan, vérification et revue avant intégration. La boucle revient à la prochaine tâche précise.Ouvrir le schéma en grand
Utiliser Codex pour développer un projet de bout en bout.Schéma en français.

Lecture du schéma

Vision produit → dépôt et documentation → tâche précise → plan Codex → validation humaine → implémentation → vérification → revue et compréhension → merge et itération. La boucle revient à la définition de la prochaine tâche. Le dépôt conserve la mémoire du projet ; Codex exécute dans un cadre validé, tandis que je garde la maîtrise des décisions et de l’intégration.

Les changements importants passent par une session de revue distincte de l’implémentation. Avant l’intégration, je relis le code, vérifie les résultats et m’assure de comprendre les choix et leurs conséquences. Codex propose, code, teste et documente ; je décide et valide.

Codex dans la documentation OpenAI

Et votre projet ?

Commençons par votre besoin.

Un objectif, une idée à tester ou un système à faire évoluer : échangeons sur la première étape.

Parlons de votre projet