Pas seulement coder
Je m’entraîne à livrer une tâche complète : comprendre le besoin, isoler le changement, vérifier les effets de bord et produire une livraison relisible.
Workflow agence
Une méthode de travail proche d’une équipe produit.
N’ayant pas encore d’expérience agence réelle, j’ai volontairement construit mes projets avec une méthode proche des conditions d’équipe : tickets, branches Git, commits lisibles, pull requests, reviews, CI, tests, documentation et corrections itératives.
Réduire le risque
L’objectif est de rendre mon travail lisible et vérifiable : scope clair, commits propres, PR documentées, checks, captures et limites connues.
M’intégrer à une équipe
Je travaille ma capacité à rejoindre un workflow déjà en place : conventions Git, tickets, branches, PR, review, CI, standards qualité et documentation.
Review simulée
Travailler avec une contrainte externe.
J’ai utilisé l’IA comme support pour reproduire une partie du cadre d’équipe : première implémentation cadrée, revue de PR avec Codex Review, conversations à résoudre, demandes de correction et checks à relancer avant de considérer une tâche acceptable.
Codebase existante
Ce travail m’a entraîné à intervenir sur du code que je ne maîtrise pas immédiatement, à respecter les patterns existants, à corriger une implémentation proposée, à justifier mes choix et à intégrer mes changements.
Méthode appliquée
Le workflow que je reproduis sur mes projets.
1. Ticket
Une tâche part d’un besoin cadré : objectif, scope, fichiers probables, risques et critères de validation.
2. Branche
Chaque sujet est isolé dans une branche thématique pour éviter les changements mélangés et garder une lecture claire.
3. Commit
Je vise un commit = une intention, avec un message compréhensible et un diff qui raconte une étape précise.
4. Pull request
La PR sert à relire le changement comme une livraison : contexte, impact, risques, choix techniques et vérifications.
5. Review
Je challenge la logique métier, la sécurité, les edge cases, la maintenabilité et les effets de bord possibles.
6. CI & tests
Les checks pertinents doivent passer : lint, typecheck, tests ciblés ou validation manuelle selon le risque du changement.
7. Corrections
Une review n’est pas décorative : je reprends les points faibles, simplifie ce qui doit l’être et relance les vérifications.
8. Documentation
Je documente les décisions importantes, les limites connues et les points à reprendre quand cela aide la maintenance.
Cas concret
Socially comme terrain d’entraînement principal.
Socially m’a permis de pratiquer ce workflow sur une vraie codebase fullstack : auth, onboarding, feed, posts, commentaires, notifications, messagerie, settings, Prisma/PostgreSQL, tests et documentation.
Ce que j’ai travaillé
Tickets Linear, branches par ticket, commits structurés, pull requests, reviews, corrections post-review, checks CI/CD, tests ciblés, README, documentation et suivi des limites produit.
Standards personnels
Ce que je cherche à rendre vérifiable.
Changements isolés
Limiter le scope d’une tâche pour faciliter la review et éviter les refactors cachés dans une feature.
Décisions explicites
Expliquer les compromis techniques quand un choix peut avoir un impact produit, sécurité ou maintenance.
Validation concrète
Ne pas considérer une tâche terminée uniquement parce que le code compile : vérifier le comportement attendu.