Si vous êtes sur le point de commander un logiciel, on vous demandera de valider un processus que vous n’avez jamais mené vous-même : une phase de découverte, une série de sprints, un cycle de QA, un plan de livraison. Savoir ce que recouvrent ces mots est ce qui vous permet de distinguer un plan réaliste d’un plan coûteux, et une équipe qui a déjà fait cela d’une équipe qui devine.
Le développement logiciel est le processus consistant à planifier, concevoir, construire, tester, déployer et maintenir un logiciel. Il fonctionne par cycles qui se répètent plutôt qu’en une seule passe linéaire, et il mobilise des développeurs, des ingénieurs QA, des designers et un responsable produit ou projet. Le terme va d’une simple application mobile à une plateforme d’entreprise déployée sur plusieurs années.
Ce guide explique à quoi ressemble réellement ce processus, qui fait quoi, les méthodologies dont on vous parlera, les principaux types de logiciels construits, ce qui fait bouger le coût, et les modèles de collaboration sous lesquels vous pouvez l’acheter. Redwerk a mené ce processus sur plus de 170 projets depuis 2005, en ingénierie de produits logiciels sur mesure pour des clients d’Amérique du Nord et d’Europe de l’Ouest.
Ce qu'est le développement logiciel en pratique
Au fond, le développement logiciel est une boucle à six étapes : planifier, concevoir, construire, tester, déployer, maintenir.
Ce qui compte, c’est qu’elle se répète. Une équipe planifie une petite partie du produit, la construit, apprend quelque chose qui change le plan, et entame le tour suivant avec ce qu’elle sait désormais.
C’est la chose la plus utile à intégrer pour un décideur non technique. Quand un prestataire présente un plan où chaque phase se déroule exactement une fois, dans l’ordre, sans retour d’information entre elles, il décrit un document, pas un processus de livraison.
Qui intervient réellement
Une équipe projet type comporte cinq rôles, et vous les rencontrerez généralement tous :
- Les développeurs écrivent le code. Sur la plupart des projets, ils se répartissent entre frontend (ce que voit l’utilisateur) et backend (données, logique, intégrations).
- Les ingénieurs QA testent le logiciel de façon délibérée et systématique, en cherchant comment il casse avant que vos utilisateurs ne le découvrent.
- Les designers décident de l’apparence du produit et de la façon dont un utilisateur y circule. Sur un logiciel métier, cela compte plus qu’on ne le croit, car un outil interne dans lequel personne ne sait naviguer finit inutilisé.
- Un responsable produit ou projet porte le périmètre, la séquence et le calendrier, et constitue généralement votre interlocuteur principal.
- Un responsable technique de compte, sur un travail externalisé, est la personne expérimentée qui répond de la collaboration dans son ensemble, et non d’un sprint en particulier.
On cherche beaucoup ce que signifie le métier de développeur logiciel, et la réponse honnête est qu’un développeur est la personne qui écrit et maintient le code, mais livrer un logiciel qui fonctionne exige aussi les quatre autres rôles. Une équipe composée uniquement de développeurs, sans QA et sans personne pour porter le périmètre, est une forme d’échec courante et coûteuse.
Le processus de développement logiciel, étape par étape
Ces étapes ne pèsent pas toutes le même poids. Les premières sont peu coûteuses à bien faire et chères à refaire, tandis que les dernières sont celles où le progrès devient visible et où l’essentiel du budget se dépense. Le temps qu’un prestataire consacre aux deux premières est un signal honnête de sa façon de travailler.
Découverte et cadrage
C’est l’étape que la plupart des projets sautent et regrettent ensuite. La découverte est le moment où l’on établit ce que le logiciel doit faire, qui l’utilise, à quoi il se connecte, et ce que signifie “terminé”. Elle produit un périmètre sur lequel on peut réellement chiffrer.
La sauter ne fait pas économiser d’argent. Cela déplace le coût à un moment plus défavorable, car les exigences finissent par apparaître de toute façon, simplement plus tard, en pleine construction, quand changer de direction signifie jeter du travail.
Vous n’avez pas besoin d’un cahier des charges complet pour démarrer. La plupart des clients n’en ont pas. Ce dont vous avez besoin, c’est d’une manière structurée de le constituer, et c’est à cela que sert une phase de découverte, ainsi que d’un livrable écrit que tout le monde accepte, ce que produisent les services de spécification fonctionnelle.
Conception et architecture
Deux choses se passent ici. Les designers travaillent l’interface et les parcours utilisateur. Les ingénieurs travaillent l’architecture : la stack, le modèle de données, la façon dont le système se découpe en parties, et la manière dont il absorbera la croissance.
Les décisions d’architecture sont celles qui coûtent cher à défaire. Choisir une mauvaise structure de base de données ou coupler deux systèmes qui auraient dû rester séparés est une décision que vous continuerez à payer longtemps après la mise en ligne. Une équipe qui a déjà construit quelque chose de similaire sait où ce type de conception a tendance à casser, et c’est précisément ce que vous lui achetez à cette étape.
Construction, tests et déploiement
La livraison moderne est itérative. L’équipe construit une tranche fonctionnelle du produit, la teste, la met quelque part où vous pouvez cliquer dessus, puis recommence. Vous devez vous attendre à voir quelque chose de fonctionnel en quelques semaines, pas à la fin.
Les tests avancent en parallèle de la construction, pas après. La QA écrit des tests à mesure que les fonctionnalités arrivent, si bien qu’un bug trouvé un mardi coûte une heure au lieu de resurgir trois mois plus tard, mêlé à du code construit par-dessus.
Le déploiement est une discipline à part entière. Mettre du code sur des serveurs de façon fiable, répétable et réversible, c’est ce qui sépare une livraison que vous pouvez faire un jeudi après-midi d’une livraison qui exige un week-end et un plan de retour arrière.
Pour le détail phase par phase du cycle de vie complet, voyez le guide Redwerk des meilleures pratiques du SDLC. Si vous avez déjà un processus et voulez savoir s’il tient, la liste de contrôle d’audit SDLC en est la version diagnostique.
Maintenance et itération
Un logiciel n’est pas terminé au moment de sa mise en ligne. Les dépendances vieillissent, les correctifs de sécurité arrivent, les navigateurs changent, et votre activité réclame des choses que le périmètre initial n’avait jamais imaginées. Budgéter la construction sans la maintenance est l’un des moyens les plus sûrs de se retrouver deux ans plus tard avec une application que personne ne peut toucher sans risque.
Agile, cycle en V et hybride comparés
La méthodologie, c’est la façon dont l’équipe organise la boucle. Trois formes couvrent presque tout ce qu’on vous proposera.
Agile
Des cycles courts de deux à quatre semaines, produisant chacun un logiciel fonctionnel. Le périmètre s’adapte au fil des apprentissages.
Le travail produit dont les exigences vont évoluer, et la majorité des logiciels commerciaux
Plus difficile à chiffrer d’emblée en un montant fixe, et demande votre implication tout du long
Cycle en V
Les phases s’enchaînent, chacune validée avant que la suivante ne commence. Le périmètre est figé au départ.
Les travaux à périmètre fixe, les environnements réglementés, les projets dont la spécification est vraiment complète et stable
Le changement coûte cher, et les problèmes apparaissent tard car les tests arrivent vers la fin
Hybride
Périmètre et budget fixes au niveau du contrat, livraison agile à l’intérieur
Les clients qui ont besoin de certitude budgétaire mais construisent quelque chose de vraiment nouveau
Exige de la rigueur sur ce qui entre dans le périmètre, sinon cela devient un cycle en V avec des sprints
Le développement logiciel agile est le choix par défaut pour la plupart du travail produit moderne, et à juste titre. Ce n’est pas automatiquement la bonne réponse. Si vous construisez contre une spécification réglementaire qui ne changera pas, le cérémonial des cycles de deux semaines ajoute de la charge sans apporter beaucoup d’apprentissage.
Les principaux types de développement logiciel
Le mot “logiciel” recouvre une grande variété, et le type détermine les outils, l’équipe, le calendrier et les contraintes.
- Le développement web construit des applications qui tournent dans un navigateur. C’est la forme la plus courante pour un logiciel métier, car il n’y a rien à installer et les mises à jour atteignent tout le monde en même temps. Les stacks habituelles incluent React, Vue.js, Angular, .NET, Django et PHP.
- Le développement mobile construit pour iOS et Android, en natif (Swift, Kotlin) ou en multiplateforme (Flutter). Les contraintes sont la validation par les magasins d’applications, la fragmentation des appareils, et le fait que vos utilisateurs seront sur une mauvaise connexion.
- Le développement desktop construit un logiciel installé sur une machine. Cela reste la bonne réponse pour du traitement local intensif, le travail hors ligne et une intégration profonde au système d’exploitation.
- Le développement embarqué et IoT construit un logiciel qui tourne sur du matériel, où la mémoire est limitée, les mises à jour difficiles à diffuser, et où un bug peut signifier un appareil physique qui se comporte mal sur le terrain.
Logiciel sur mesure ou solution du marché
Acheter un produit existant est plus rapide et moins cher, et pour un problème déjà résolu comme la paie ou la messagerie, c’est presque toujours le bon choix. Construire sur mesure a du sens quand le processus que vous automatisez est vraiment propre à votre façon de travailler, quand la charge d’intégration liée à l’assemblage de plusieurs outils du marché dépasse le coût d’un système unique qui vous va, ou quand le logiciel est le produit que vous vendez.
Une voie médiane utile consiste à construire la plus petite version qui prouve l’idée avant de s’engager sur le système complet. Comment construire un MVP correctement explique comment le cadrer pour qu’il reste une fondation et non un produit jetable.
Ce qui détermine vraiment les coûts de développement logiciel
Personne ne peut chiffrer votre projet à partir d’un nom de catégorie. Ce qu’on peut vous dire, c’est quelles variables font bouger le montant, et voici celles qui comptent le plus :
- La clarté du périmètre. Le facteur le plus important, de loin. Un système bien spécifié se chiffre serré. Un système flou se chiffre large, parce que l’équipe met un prix sur son incertitude.
- Les intégrations. Chaque système externe auquel vous vous connectez ajoute du travail difficile à estimer, car vous ne contrôlez pas l’autre bout. Trois intégrations, ce n’est pas le même projet que zéro.
- Les exigences de conformité et de sécurité. La santé, la finance et le secteur public imposent des obligations d’audit, de traitement des données et de documentation qui représentent un vrai effort d’ingénierie.
- La migration de données. Transférer proprement des années d’enregistrements existants vers un nouveau système est systématiquement sous-estimé. Les données héritées sont plus désordonnées que dans les souvenirs.
- Le niveau d’expérience et la composition de l’équipe. Les ingénieurs seniors coûtent plus cher à l’heure et généralement moins cher au résultat, car les erreurs coûteuses sont architecturales et se commettent tôt.
- La profondeur du design. Une interface client soignée et très utilisée n’est pas le même investissement qu’un écran d’administration interne utilisé par six personnes.
- La traîne de maintenance. Le support continu, l’hébergement et les mises à jour sont une ligne récurrente, pas un arrondi sur la construction.
Vous voulez savoir où se situe votre propre projet ? Redwerk fournit des estimations gratuites. Dites-nous ce que vous construisez, même si les détails restent approximatifs, et nous reviendrons vers vous avec une fourchette réaliste et les hypothèses qui la sous-tendent.
Modèles de collaboration : comment acheter du développement logiciel
Le modèle de collaboration décide de qui porte le risque que les choses prennent plus de temps que prévu. C’est toute la question, et il vaut mieux la comprendre avant de comparer des devis.
Forfait
Une somme convenue pour un périmètre convenu
Les projets bien définis, aux exigences stables et avec une ligne d’arrivée claire
Chaque changement devient une négociation, et le devis porte une prime de risque
Régie
Pour les heures réellement travaillées
Un périmètre évolutif, un travail à forte part de découverte, un développement produit continu
Demande de la confiance et une visibilité réelle sur l’usage des heures
Équipe dédiée
Un tarif mensuel pour une équipe qui ne travaille que sur votre produit
Les travaux de longue durée, combler un manque de capacité ou de compétences que vous ne pouvez pas recruter
Ne devient rentable que sur plusieurs mois, pas pour une intervention courte et ponctuelle
Renfort d’équipe
Par spécialiste ajouté à votre équipe existante
Vous avez déjà une équipe et un processus qui fonctionnent et il vous manque une compétence précise
Le pilotage, l’architecture et le résultat restent à votre charge
Le choix découle en général du degré de certitude sur votre périmètre. Le forfait récompense la certitude. La régie et l’équipe dédiée s’accommodent de la réalité : vous apprendrez des choses pendant la construction.
Pour un traitement plus long de la place d’une équipe de développement dédiée face aux alternatives, voyez CTO fractionnel contre conseil en développement logiciel contre renfort d’équipe, et pour la question de fond entre construire et acheter l’équipe, développement logiciel interne contre externalisé.
Ce qu'il faut peser avant de recruter une équipe externe
L’externalisation n’est pas toujours le bon choix, et un prestataire qui vous dit le contraire est en train de vendre.
La première objection soulevée porte sur la connaissance. Si une équipe externe le construit, le savoir part-il à la fin du contrat ? C’est en réalité une question de documentation et de transfert. Un prestataire qui écrit les choses, tient la spécification à jour et remet une base de code documentée vous laisse plus de connaissance exploitable qu’une équipe interne qui gardait tout dans la tête de deux personnes. Demandez à tout prestataire quelle documentation accompagne la mission et à qui elle appartient à la fin. Une réponse vague sur ce point vous en dit plus que n’importe quelle présentation commerciale.
Gardez le travail en interne quand vous avez déjà une équipe d’ingénierie solide avec de la capacité disponible, car ajouter un groupe externe crée une charge de coordination dont vous n’avez pas besoin.
Réfléchissez bien avant d’externaliser si personne en interne ne peut trancher les décisions produit. Une équipe externe peut travailler sans cahier des charges complet, et une bonne équipe s’y attend. Ce dont aucune équipe ne peut se passer, c’est de quelqu’un de votre côté habilité à répondre aux questions et à décider. Sans cela, le projet s’enlise, peu importe qui écrit le code.
Sur les délais, le développement assisté par IA a déplacé la ligne. Un travail qui prenait un trimestre peut aboutir en quelques semaines quand le problème est bien compris et le code conventionnel, et c’est aujourd’hui une question légitime à poser à un prestataire. Ce qu’elle n’a pas compressé, c’est le temps nécessaire pour s’accorder sur ce que l’on construit, ni pour s’intégrer à des systèmes que vous ne contrôlez pas. Pour une échéance très courte sur un problème répandu, acheter un produit du marché et le paramétrer reste parfois la voie la plus rapide.
Les termes du développement logiciel que vous entendrez
Sprint, backlog, dette technique, CI/CD, préproduction, refactorisation, API. Les prestataires emploient ces mots en permanence et s’arrêtent rarement pour les définir.
Redwerk maintient un glossaire en langage clair exactement pour cela : les termes du développement logiciel, les 60 à connaître. Cela vaut un survol avant votre premier atelier de cadrage, car pouvoir demander “est-ce dans ce sprint ou dans le backlog ?” change la conversation.
Comment Redwerk mène ce processus
Redwerk construit des logiciels depuis 2005, avec plus de 170 clients en Amérique du Nord et en Europe de l’Ouest. Trois choses sur notre façon de mener le processus méritent d’être connues si vous comparez des équipes.
Nous commençons par une découverte structurée, et nous n’exigeons pas que vous arriviez avec un cahier des charges complet. La plupart des clients n’en ont pas. Élaborer la spécification ensemble fait partie du travail, ce n’est pas un préalable pour le commencer.
Nous affectons selon la stack, pas seulement selon le secteur. Si votre système tourne sur .NET et Azure, vous obtenez des ingénieurs qui ont livré des systèmes .NET et Azure, et c’est ce qui rend une prise en main courte réaliste plutôt qu’aspirationnelle.
Nous communiquons volontairement plus que nécessaire. Le thème le plus constant dans les retours de nos clients est qu’ils savaient toujours où en était le projet. Pour des décideurs non techniques qui dépendent entièrement de l’équipe qu’ils ont recrutée, c’est la différence entre un projet maîtrisé et un projet anxiogène.
Si vous en êtes au tout début et voulez faire définir le bon périmètre et la bonne approche avant que quiconque n’écrive du code, commencez par le conseil en développement logiciel.
Questions fréquentes
Qu'est-ce que le développement logiciel en termes simples ?
Le développement logiciel est le travail consistant à planifier, construire, tester et maintenir des programmes informatiques. Il mobilise une équipe de développeurs, de testeurs, de designers et d’un responsable qui travaillent par cycles répétés, plutôt qu’une seule personne écrivant du code du début à la fin.
Quelle est la différence entre développement logiciel et ingénierie logicielle ?
Les termes se recoupent largement et sont souvent employés indifféremment. L’ingénierie logicielle suppose généralement un accent plus fort sur le processus formel, l’architecture et la maintenabilité à long terme, tandis que le développement logiciel est le terme plus large qui couvre tout le travail de création d’un logiciel.
Quelles sont les étapes du cycle de vie du développement logiciel ?
Le cycle de vie du développement logiciel comporte six étapes : planification, conception, développement, test, déploiement et maintenance. Dans la pratique moderne, elles se répètent par cycles courts au lieu de se dérouler une seule fois en séquence, si bien qu’une équipe revient de nombreuses fois à la planification et à la conception au cours d’un projet.
Combien de temps dure un projet de développement logiciel ?
Cela dépend surtout du périmètre et de la complexité des intégrations. Un produit minimum viable prouvant un seul parcours central se compte généralement en mois, tandis qu’une plateforme complète avec plusieurs intégrations, une migration de données et des exigences de conformité s’étend nettement plus longtemps. Une phase de découverte est ce qui transforme cette fourchette en calendrier réel.
Ai-je besoin d'un cahier des charges complet avant de recruter une équipe ?
Non. La plupart des clients démarrent sans. Une bonne équipe mène une phase de découverte structurée pour établir le périmètre en commun. Ce dont vous avez besoin, en revanche, c’est de quelqu’un de votre côté habilité à prendre les décisions produit pendant la construction.
Découvrez comment nous avons aidé AWE Learning à migrer de l'infrastructure sur site vers le cloud, et à atteindre des utilisateurs au-delà des États-Unis grâce à une solution SaaS évolutive
