Un projet logiciel commence par une idée. Entre cette idée et le code en production, il y a un chemin en six phases. Pas une ligne droite — un cycle qui itère, s'ajuste, revient en arrière quand nécessaire.
Voici comment ça fonctionne.
Phase 1 : De l'idée à la spécification
Tout commence par une demande. Un client qui veut filtrer ses factures par date. Une équipe qui identifie un besoin. Un fondateur qui a une vision.
La première étape consiste à transformer cette idée en spécification claire. Pas un document de 50 pages — juste assez pour que l'équipe comprenne tous la même chose.
Exemple de bonne spec : "En tant que client, je veux filtrer mes factures par date pour retrouver rapidement un paiement spécifique."
Exemple de mauvaise spec : "Ajouter un date picker moderne et intuitif avec animation."
La différence ? La première définit le problème à résoudre. La seconde impose une solution avant même d'avoir analysé les contraintes techniques.
Durée typique : 1 heure à 3 jours selon la complexité du feature.
Erreur classique : Spécifications vagues ou trop détaillées. Le sweet spot : définir clairement le quoi sans contraindre le comment.
Phase 2 : Architecture et design
Une fois la spec validée, l'équipe technique conçoit la solution. Trois aspects en parallèle :
Database schema : Quelles tables ? Quelles colonnes ? Quels indexes pour optimiser les performances ?
```sql invoices: id, user_id, amount, date, status INDEX sur date pour requêtes de filtre ```
API design : Quels endpoints ? Quelle structure de données en entrée et sortie ?
``` GET /invoices?start_date=2026-01-01&end_date=2026-12-31 Response: { invoices: [...] } ```
Interface utilisateur : Wireframes ou prototypes. Pas le design visuel final — juste la structure fonctionnelle.
Durée typique : 2 heures à 2 jours.
Erreur classique : Concevoir l'interface avant l'API. Résultat : promesses visuelles que le backend ne peut pas tenir efficacement. L'ordre optimal : base de données → API → interface.
Phase 3 : Développement
Le code commence. Un développeur crée une branche Git pour isoler son travail.
```bash git checkout -b feature/invoice-filters ```
Il développe localement. Teste manuellement. Itère. Quand le code fonctionne, il le publie et ouvre une Pull Request (PR).
Une Pull Request est une proposition de changement. Elle permet à d'autres développeurs de lire le code, identifier les problèmes potentiels, suggérer des améliorations.
Flow typique : 1. Développement local 2. Commits réguliers avec messages descriptifs 3. Push vers le dépôt distant 4. Ouverture d'une PR avec description et contexte 5. Code review par un collègue 6. Ajustements selon feedback 7. Approbation et merge
Durée typique : 3 heures à 2 semaines selon la complexité.
Bon signe : Commits atomiques, PR focalisée sur un seul feature, review constructive, tests inclus.
Mauvais signe : Commits géants ("Updated stuff"), PR de 50 fichiers, pas de review, merge immédiat.
Phase 4 : Tests
Le code fonctionne sur la machine du développeur. Fonctionne-t-il dans tous les contextes ?
Trois niveaux de tests :
Unit tests : Chaque fonction testée isolément avec des données contrôlées.
```javascript test('filterInvoicesByDate returns correct count', () => { const invoices = mockInvoiceData(); const filtered = filterByDate(invoices, '2026-01-01', '2026-12-31'); expect(filtered.length).toBe(12); }); ```
Integration tests : Les composants ensemble. L'API interroge la base de données, traite les résultats, retourne la réponse.
Staging environment : Environnement identique à la production, mais isolé. L'équipe teste le feature en conditions réelles avant le déploiement public.
Durée typique : 1 heure à 3 jours.
Règle pragmatique : Features critiques (paiements, authentification, données sensibles) nécessitent des tests exhaustifs. Features cosmétiques peuvent être validées manuellement.
Phase 5 : Déploiement
Le code testé et approuvé passe en production.
Déploiement moderne (CI/CD) :
Le merge de la Pull Request déclenche automatiquement un pipeline : 1. Compilation du code 2. Exécution de la suite de tests 3. Déploiement automatique vers staging 4. Validation finale 5. Déploiement progressif vers production (10% → 50% → 100%) 6. Monitoring des erreurs et performances
Durée typique : 5 à 15 minutes avec un pipeline automatisé.
Déploiement manuel (à éviter) : Copie de fichiers via FTP, redémarrage manuel du serveur, absence de rollback. Résultat : downtime, bugs non détectés, stress.
Outils courants : GitHub Actions, GitLab CI, AWS CodePipeline, Vercel, Netlify.
Insight clé : Un bon déploiement est ennuyeux. Automatique, rapide, réversible. Si c'est stressant, le pipeline a un problème.
Phase 6 : Feedback et itération
Le feature est en production. L'équipe observe.
Trois sources de feedback :
Analytics : Taux d'utilisation, patterns de comportement, performance technique.
Bug reports : "Le filtre ne fonctionne pas sur Safari." "Les dates avant 2020 causent une erreur."
Feature requests : "Excellent. Serait-il possible de filtrer également par montant ?"
Actions selon le feedback :
- Bug critique → Fix immédiat, nouveau cycle accéléré
- Amélioration mineure → Ajout au backlog, prochain sprint
- Feature majeure → Retour en Phase 1, nouvelle spécification
Exemple concret : Filtre de factures
Jour 1 : Demande client. Spécification rédigée en 2 heures.
Jour 2 : Design de la base de données, de l'API, wireframe UI. 4 heures.
Jours 3-4 : Développement backend et frontend. 12 heures. Pull Request ouverte.
Jour 5 : Tests automatisés, validation en staging, code review. 3 heures. PR approuvée et mergée.
Jour 5 (fin de journée) : CI/CD déclenché. Déploiement en production. 15 minutes.
Semaine suivante : Analytics montrent 40% d'utilisation. 2 bugs mineurs corrigés. Demande de filtre par montant ajoutée au backlog.
Total : 5 jours calendrier, environ 20 heures de travail effectif.
Les méthodologies
Waterfall (cascade) : Approche séquentielle. Planification complète → design complet → développement complet → tests complets → déploiement unique. Adapté aux projets à spécifications fixes (sites corporatifs, systèmes legacy). Rigide pour les produits exploratoires.
Agile (itératif) : Cycles courts de 1 à 2 semaines. Livraison rapide, ajustements constants selon feedback utilisateur. Adapté aux SaaS et produits évolutifs. Nécessite discipline et communication.
DevOps / CI-CD (continu) : Automatisation maximale. Déploiements multiples par jour. Chaque commit peut potentiellement aller en production. Adapté aux équipes matures avec infrastructure cloud. Setup complexe, efficacité élevée.
Ce qui compte
Trois indicateurs de succès :
1. Spécification claire. Pas d'ambiguïté sur le problème à résoudre.
2. Tests qui passent. Le code fonctionne. Pas "presque" — fonctionne.
3. Déploiement sans régression. L'ajout d'une feature ne casse pas les features existantes.
Trois erreurs courantes :
Sur-planification : 3 mois de spécifications pour 2 semaines de développement.
Sous-testing : "On testera après le lancement."
Absence de feedback : Code déployé, puis silence pendant des mois.
Approche pragmatique : Cycles courts (1-2 semaines) pour l'exploration. Cycles moyens (1 mois) pour la consolidation. Cycles longs (3+ mois) uniquement si les spécifications sont contractuellement fixes.
La réalité non-linéaire
Le cycle théorique est linéaire. La pratique ne l'est jamais.
Le développement révèle que la spécification était floue. Retour en Phase 1.
Les tests exposent des failles architecturales. Retour en Phase 2.
Le feedback utilisateur invalide les hypothèses initiales. Retour en Phase 1.
Cette itération n'est pas un échec. C'est le processus d'apprentissage. Chaque passage dans le cycle améliore le produit.
Le meilleur cycle de développement n'est pas celui qui suit un plan parfait. C'est celui qui permet d'apprendre rapidement, corriger efficacement, et livrer régulièrement.
De l'idée au bug report. Du bug report à la prochaine idée. Le cycle tourne. C'est le développement logiciel.
