Comment fonctionne le développement logiciel — de l'idée au produit en ligne

Se lancer dans un projet logiciel ressemble pour beaucoup de clients à une boîte noire. Vous savez ce que vous voulez — une plateforme, une application, un système interne — mais vous ne savez pas exactement comment passer de cette idée à un produit fonctionnel. Ni ce qui doit se passer entretemps.

Ce qui suit est un parcours honnête à travers l'ensemble du processus : ce qui se passe à chaque phase, combien de temps cela prend, ce que vous devez apporter en tant que client, et d'où viennent la plupart des surprises.

Phase 1 : Discovery et exigences (2 à 4 semaines)

Avant qu'une seule ligne de code soit écrite, il doit être clair ce qui doit exactement être développé — et pourquoi. Cela semble évident, mais la plupart des projets qui déraillent le font déjà ici.

Pendant la phase de discovery, l'agence analyse votre contexte métier, vos utilisateurs, l'environnement technique (systèmes existants, connexions, structures de données) et le périmètre réel du projet. Le résultat est une spécification détaillée : qui sont les utilisateurs, quels flux ils parcourent, quelles décisions ils doivent pouvoir prendre dans le système, et à quoi ressemble l'architecture technique.

Ce que vous faites pendant cette phase : être disponible. Des entretiens avec vous et vos membres d'équipe, parfois aussi avec des clients ou des utilisateurs finaux. Fournir des documents sur votre situation actuelle. Donner votre avis sur les projets de périmètre. Ce n'est pas une phase passive pour le client.

Ce que vous en obtenez : une spécification qui constitue aussi la base du devis. Les agences qui sautent cette phase donnent des estimations basées sur des hypothèses — et celles-ci ne se vérifient presque jamais.

Phase 2 : Design et UX (2 à 4 semaines, parfois en parallèle du développement)

Une fois les exigences claires, le produit est pensé visuellement. Cela va au-delà des couleurs et des logos : une bonne phase UX détermine comment les utilisateurs se déplacent dans le système, quelles informations ils voient à quel moment, et comment l'interface rend des fonctionnalités complexes compréhensibles.

En pratique, un designer produit des wireframes — des versions schématiques de chaque page ou écran — puis des prototypes visuels. Les outils modernes comme Figma permettent de cliquer sur un prototype comme s'il fonctionnait déjà, bien avant qu'un développeur soit intervenu.

Ce que vous faites pendant cette phase : donner votre avis sur les wireframes et les prototypes. C'est le moment de dire ce que vous ne comprenez pas, ce qui ne va pas, ou ce qui manque. C'est gratuit maintenant ; si cela doit être modifié pendant la phase de construction, cela coûte du temps et de l'argent.

Erreur fréquente : les clients regardent le style visuel pendant cette phase plutôt que la logique. « Les couleurs sont belles » ne dit rien sur si le système fonctionne logiquement. Concentrez-vous sur les flux.

Phase 3 : Développement (8 à 24 semaines selon le périmètre)

La phase de construction est la plus longue, et pour la plupart des clients la plus opaque. Les développeurs travaillent sur le frontend (ce que l'utilisateur voit), le backend (la logique et les données derrière) et les intégrations (connexions avec d'autres systèmes).

Dans une approche agile — désormais la norme dans les agences sérieuses — les développeurs travaillent en sprints d'une ou deux semaines. À la fin de chaque sprint, vous voyez un logiciel fonctionnel. Pas un rapport ou une présentation : de la fonctionnalité réelle et cliquable.

Ce que vous faites pendant cette phase : être présent aux sprint reviews, répondre aux questions quand quelque chose est flou, et fixer des priorités quand le périmètre est sous pression. Vous n'avez pas besoin d'avoir des connaissances techniques, mais vous devez être disponible. Un client qui ne répond pas pendant deux semaines bloque une équipe de quatre développeurs.

Ce que les équipes rencontrent : une complexité technique imprévue (une connexion qui fonctionne différemment de ce qui est documenté, une structure de données qui nécessite une adaptation), un élargissement du périmètre qui ne rentre pas dans la planification initiale, et des dépendances vis-à-vis de tiers (prestataires de paiement, API gouvernementales) qui causent des retards.

Phase 4 : Tests et contrôle qualité (2 à 4 semaines)

Les tests ne sont pas une phase que vous ajoutez à la fin ; ils commencent dès le premier sprint. Mais avant que le logiciel soit mis en ligne, une période de test plus intensive suit.

Les agences professionnelles travaillent avec des tests automatisés (du code qui teste d'autre code), des tests d'acceptation manuels (un testeur parcourt tous les scénarios), et des tests utilisateurs (de vrais utilisateurs ou des testeurs internes qui essaient le produit). Les bugs sont enregistrés, priorisés et corrigés.

Ce que vous faites pendant cette phase : effectuer des tests d'acceptation utilisateur (UAT). Vous et votre équipe testez le système depuis votre propre réalité — avec des données réelles, dans des scénarios réels. Vous connaissez les cas limites qu'un testeur externe n'imaginera jamais.

Attente réaliste : il y a toujours des bugs. La question n'est pas de savoir si vous en trouvez, mais à quelle vitesse ils sont corrigés et à quel point ils sont sérieux. Un système n'est jamais parfaitement exempt d'erreurs ; l'essentiel est que les chemins critiques fonctionnent et que le reste soit priorisé.

Phase 5 : Déploiement et mise en ligne (1 à 2 semaines)

Le logiciel est mis en ligne. Cela semble simple, mais il y a plusieurs étapes : configurer l'environnement de production, migrer les données (s'il y a des données legacy à transférer), charger progressivement le système, et surveiller si tout reste stable.

Les bonnes agences font un « soft launch » ou un « staged rollout » : le système est mis en ligne pour un petit groupe d'utilisateurs avant que la population plus large y ait accès. Cela permet de détecter les problèmes à l'échelle tôt.

Ce que vous faites pendant cette phase : assurer la communication vers vos utilisateurs ou collaborateurs, rendre disponibles la formation ou la documentation, et être présent si des questions ou des problèmes surgissent directement après le lancement.

Erreur fréquente : les clients s'attendent à ce que le lancement soit le point final. Ce n'est pas le cas. Les premières semaines après le lancement sont intenses : les utilisateurs découvrent des choses que les testeurs n'ont jamais testées, la charge de pointe révèle des goulots d'étranglement, et les retours affluent.

Phase 6 : Maintenance et développement continu (en continu)

Les logiciels ne sont pas des produits que vous achetez et oubliez. Ils ont besoin de maintenance : mises à jour de sécurité, mises à jour des bibliothèques et frameworks, surveillance de la disponibilité et des performances, et adaptations quand l'activité change.

Les bonnes agences proposent un contrat de maintenance ou un accord de retainer : un montant mensuel fixe pour la maintenance et une capacité convenue pour le développement continu. Cela évite d'avoir à refaire un devis à chaque fois pour de petites modifications.

Les trois questions à poser à l'avance :

Qui est propriétaire du code et de l'infrastructure ?

Quels sont les coûts si vous souhaitez étendre ou migrer plus tard ?

Comment l'agence gère-t-elle les failles de sécurité découvertes après coup ?

Délai et budget : attentes réalistes

Un parcours typique pour un projet logiciel de taille moyenne (une application web avec des comptes utilisateurs, de la gestion de données et quelques intégrations) dure quatre à huit mois du premier entretien à la mise en ligne, et coûte 60 000 à 200 000 € selon le périmètre.

Les applications simples ou les outils internes sont plus rapides et moins chers. Les plateformes complexes avec plusieurs groupes d'utilisateurs, des fonctionnalités temps réel et de nombreuses intégrations prennent plus de temps et coûtent plus cher.

Ce que les clients ne s'attendent souvent pas : l'investissement en temps interne de leur propre équipe. En moyenne, un client consacre deux à quatre heures par semaine activement à un projet en cours — feedback, décisions, contenu, données de test. Intégrez cela dans votre calcul.

Les trois surprises que rencontre presque tout premier client

Le périmètre grandit toujours. À mesure que le produit devient plus concret, vous pensez à plus de choses que vous voulez aussi. L'agile rend cela gérable — vous l'ajoutez au backlog et déterminez la priorité — mais cela a des implications budgétaires.

Les intégrations sont imprévisibles. Les connexions avec des systèmes externes (prestataires de paiement, logiciels de comptabilité, systèmes gouvernementaux) sont techniquement parfois plus complexes que prévu. La documentation est obsolète, les API se comportent différemment de ce qui est décrit, ou des solutions intermédiaires doivent être développées.

Les utilisateurs l'utilisent différemment de ce qu'on attendait. Aussi soigneusement que vous ayez réfléchi à l'UX, de vrais utilisateurs font des choses que personne n'avait prévues. Planifiez après le lancement un budget pour un premier tour d'ajustements basés sur l'utilisation.

Un projet logiciel est une collaboration, pas une commande. Les agences qui livrent les meilleurs résultats traitent le client comme un partenaire dans le processus — pas comme quelqu'un qui soumet une spécification et vient chercher un produit trois mois plus tard. Et les clients qui obtiennent les meilleurs résultats comprennent que leur implication est l'un des facteurs de succès les plus importants.