Le processus de développement logiciel, étape par étape

Le processus de développement logiciel sur mesure est le chemin que suit un projet d'une idée brute à un logiciel en production dont vous êtes propriétaire. Un tel projet comporte généralement des activités de cadrage, conception, développement, vérification, déploiement et maintenance ; leur découpage et leur ordre varient selon le modèle de cycle de vie, l'organisation et le contexte du projet, mais chez Globaprom nous les organisons en cinq étapes : cadrage, conception, build, recette et livraison. Les noms varient selon le prestataire. L'enchaînement, non. Le connaître permet de distinguer un processus sérieux d'un processus ouvert avant de signer, et de reconnaître à quelle étape vous vous trouvez une fois le travail lancé.

Écrit pour la personne qui commande le logiciel, pas pour celle qui l'écrit. Notre guide sur le développement logiciel sur mesure couvre coûts, délais et décision construire-ou-acheter ; ici le propos est la mécanique du build lui-même, ce qui se passe à chaque étape, et ce que vous devriez pouvoir vérifier avant le passage à la suivante.

Les cinq étapes que traverse tout développement

Sous n'importe quelle méthode, le travail suit le cycle de vie du développement logiciel (SDLC) : la séquence des exigences jusqu'à un système en fonctionnement et maintenu. Les équipes agiles bouclent ces étapes en cycles courts ; un développement à périmètre fixe les déroule une fois, délibérément. Dans les deux cas, ces activités sont souvent couvertes dans un projet, mais elles peuvent être itératives, parallèles ou regroupées ; leur omission peut accroître certains risques sans constituer, à elle seule, une cause démontrée de dérapage. Pour la définition complète, voyez l'entrée cycle de vie du développement logiciel.

L'enjeu de bien respecter la séquence est ancien et bien documenté. Dans le rapport CHAOS de 1994 du Standish Group, portant sur 365 répondants et 8 380 applications, 52,7 % des projets étaient classés « challenged » et 31,1 % « impaired », avec un dépassement moyen de 189 % du coût initial pour les projets concernés. Ce rapport historique associe notamment les projets en difficulté aux exigences incomplètes, au manque d'implication des utilisateurs et aux changements d'exigences ; il ne permet pas d'établir une cause unique valable pour tous les projets contemporains. Les étapes ci-dessous sont ordonnées pour limiter ce risque.

Étape 1 : exigences et cadrage

Tout ce qui suit repose sur cette étape, qui transforme votre processus en une spécification écrite. Écrans, rôles d'utilisateurs, règles métier, intégrations et critères d'acceptation, le tout dans un langage clair que vous pouvez lire et vérifier.

C'est là qu'un projet se gagne ou se perd. Un périmètre flou (« construisez-nous un portail ») est la façon dont les projets en régie gonflent, parce que chaque hypothèse tue devient une demande d'évolution plus tard. Un périmètre précis nomme ce que le logiciel fait et, tout aussi important, ce qu'il ne fait pas. En tant qu'acheteur, votre travail à cette étape est de repérer ce qui manque tant que c'est encore une phrase sur une page, pas une fonction à reconstruire. Exigez que le périmètre inclue des critères d'acceptation : les conditions précises que le logiciel fini devra remplir. Ces critères deviennent le test de l'étape quatre, ce qui explique qu'écrire maintenant évite les disputes plus tard.

Bon signe : le prestataire pose des questions inconfortables et précises sur les cas limites (que devient un paiement partiel, une commande annulée, un utilisateur à deux rôles). Mauvais signe : il acquiesce et promet de « voir ça pendant le développement ».

Étape 2 : conception et architecture

Le quoi étant réglé, cette étape décide le comment. Le modèle de données, l'approche d'intégration, le modèle de sécurité et, pour tout ce qui franchira des frontières, le plan d'internationalisation.

La plupart de ces choix vous sont invisibles et coûtent cher à changer ensuite, ce qui explique qu'ils se fassent avant toute fonction, pas pendant. La protection de la vie privée et les exigences de sécurité des données devraient être intégrées dès ces premières phases de conception, notamment dans les choix d'architecture et de fonctionnalités. Le modèle de données décide ce que le logiciel peut ou non représenter. L'approche d'intégration décide à quel point il s'intègre proprement à votre ERP, votre prestataire de paiement ou vos transporteurs. Le modèle de sécurité décide qui peut voir et faire quoi. Lorsque l'application traite des données personnelles, la conception doit aussi prévoir la minimisation des données et des paramètres par défaut protecteurs. Et si le logiciel servira un jour plus d'une langue ou d'une devise, c'est l'étape où cette capacité s'intègre à la fondation ou se rajoute douloureusement plus tard. Vous ne relirez pas la plupart de ces décisions en détail, mais vous devriez savoir qu'elles ont été prises délibérément, et pouvoir demander pourquoi.

Étape 3 : build

C'est l'étape que la plupart des gens imaginent quand ils pensent « développement » : le logiciel s'écrit vraiment. Dans notre approche, cela signifie du développement assisté par IA (intelligence artificielle) : les ingénieurs utilisent des outils de codage IA, puis soumettent chaque partie de la sortie à une revue et à des tests ; cette pratique est propre à notre méthode et ne doit pas être généralisée à tout développement assisté par IA sans éléments supplémentaires. La CNIL recommande également de sécuriser l'environnement de développement et de mettre en place le versionnage du code ; ces pratiques complètent la revue et les tests du code produit.

La seule chose à exiger pendant le build, c'est la visibilité. Vous devriez voir du logiciel qui fonctionne pendant cette étape, pas une boîte noire qui s'ouvre le jour de la mise en ligne. Des points réguliers face au périmètre repèrent la dérive tôt, quand elle est peu chère à corriger. Un processus qui devient silencieux pendant des semaines et réapparaît avec un produit fini est un processus qui cache ses problèmes de périmètre jusqu'à ce qu'il soit trop tard pour les corriger sans coût. Comment nous menons cette étape, y compris comment le code écrit par IA est relu avant de vous parvenir, est sur comment nous cadrons, construisons et relisons.

Étape 4 : recette

Maintenant le logiciel se vérifie face aux critères d'acceptation écrits à l'étape un. Cette étape, c'est la recette utilisateur (UAT) : vous, ou votre équipe, vérifiant que le logiciel fait ce que le périmètre disait, avant la mise en ligne. Pour la définition, voyez l'entrée recette utilisateur.

La recette utilisateur est une étape importante pour vérifier l'adéquation au périmètre convenu, mais son importance relative dépend du projet et elle ne constitue pas l'unique mécanisme de protection de l'acheteur. Elle peut être reliée aux critères d'acceptation définis en amont, sans remplacer les autres activités de vérification et d'assurance qualité du projet, notamment la qualité et la documentation du code. Si l'étape un a été écrite clairement, l'étape quatre n'a pas de disputes : chaque critère passe ou non, et il y a un document à pointer. Si l'étape un était floue, c'est là que les désaccords surgissent, au pire moment. Testez face à des scénarios réels, pas seulement au scénario idéal : la commande bancale, le client inhabituel, la donnée qui n'entre pas dans le moule. Un logiciel qui passe une démo peut encore échouer un mardi. Mieux vaut le trouver maintenant, le prestataire engagé, qu'en production.

Étape 5 : livraison et maintenance

Le build s'achève par le déploiement, la documentation, la formation et, sur un projet sur mesure, la propriété du code : le code source complet et le dépôt remis entre vos mains. C'est ce qui sépare posséder un logiciel de le louer.

Une vraie livraison inclut le code, la configuration d'infrastructure et les notes dont un nouveau développeur aurait besoin pour le reprendre, pas seulement un accès à une appli en fonctionnement. Après la livraison, la maintenance constitue un processus distinct qui doit être planifié, exécuté, contrôlé, revu et évalué. La remise du code peut réduire la dépendance à l'équipe d'origine, mais un logiciel reste dépendant de compétences, d'infrastructure, de mises à jour et de mesures de sécurité pour être exploité et maintenu : cela peut prendre la forme d'un forfait de suivi avec l'équipe d'origine, d'un développeur interne, ou d'un autre prestataire entièrement, puisque le code est le vôtre. Demandez à tout prestataire, avant de commencer, exactement ce que vous recevez à la livraison. La réponse vous dit si vous achetez un actif ou une laisse.

Comment l'assistance par IA change le délai, pas les étapes

Le développement assisté par IA a compressé le milieu de ce processus de façon spectaculaire, sans retirer une seule étape. La phase de build qui durait autrefois des mois dure désormais des semaines : une automatisation de flux cadrée en deux à trois semaines, une application web complète en trois à six, une plateforme multilingue en cinq à huit, du périmètre validé à la production.

Ce qui n'a pas changé, c'est la discipline autour du build. Le cadrage vient toujours d'abord, parce que l'IA ne peut pas deviner une exigence que vous n'avez pas énoncée. La recette vient toujours en dernier, parce que le code généré se vérifie comme tout autre. La livraison remet toujours un code que vous possédez. La frappe est devenue plus rapide ; le jugement, l'architecture et la responsabilité restent humains. Un prestataire qui utilise l'IA pour sauter le cadrage ou la recette ne va pas plus vite, il déplace juste le risque sur vous.

Questions fréquentes sur le processus de développement logiciel

Quelles sont les étapes du processus de développement logiciel sur mesure ?

Cinq, dans l'ordre : exigences et cadrage, conception et architecture, build, recette, et livraison avec maintenance. Ensemble elles forment le cycle de vie du développement logiciel. Les noms varient selon les prestataires et les méthodes, mais la séquence est constante, et sauter une étape est là où les projets échouent.

Qu'est-ce que le cycle de vie du développement logiciel (SDLC) ?

Le cycle de vie du développement logiciel est la séquence complète qu'un développement suit des exigences à un système en fonctionnement et maintenu. Les méthodes agiles répètent les étapes en cycles courts ; les projets à périmètre fixe les déroulent une fois. Dans les deux cas il couvre cadrage, conception, build, tests, déploiement et maintenance.

Quelle étape du développement est la plus importante ?

Les exigences et le cadrage. Un périmètre flou est la première cause de dépassements et de litiges, parce que chaque hypothèse tue devient une évolution coûteuse plus tard. Le temps passé à rendre le périmètre précis, avec des critères d'acceptation clairs, se rembourse à chaque étape suivante, surtout à la recette.

Qu'est-ce que la recette utilisateur (UAT) ?

La recette utilisateur est l'étape où vous, l'acheteur, vérifiez le logiciel fini face aux critères d'acceptation convenus au cadrage, avant la mise en ligne. Testez des scénarios réels, y compris les cas limites bancals, pas seulement le chemin de démo. Des critères clairs écrits tôt rendent cette étape rapide et sans dispute.

Le développement assisté par IA change-t-il le processus ?

Il compresse la phase de build de mois à semaines, mais les étapes restent les mêmes. Le cadrage vient toujours d'abord, la recette toujours en dernier, et la propriété du code se livre toujours à la fin. L'IA accélère la frappe ; le jugement humain, l'architecture et la relecture demeurent. Sauter des étapes, ce n'est pas de la vitesse, c'est du risque transféré.

Commencez par un périmètre que vous pouvez lire

Dites-nous le processus que vous voulez construire, et nous le transformons en un périmètre écrit avec des critères d'acceptation que vous validez avant toute ligne de code, puis un prix fixe et une date de livraison en semaines. Si un développement n'est pas le bon choix, nous le dirons, comme nous l'expliquons dans quand créer un logiciel sur mesure.

Demander un devis à prix fixe →