EP. 72 - Les 7 étapes d'un développement logiciel sur mesure

Tout comme la construction d'un immeuble nécessite un processus bien défini pour passer de la conception à la réalisation, le développement logiciel suit également un ensemble d'étapes cruciales afin de transformer une idée en une application fonctionnelle. Pour télécharger notre aide-mémoire sur les 7 étapes du développement logiciel consultez le lien suivant : https://www.openmindt.com/fr/ressources/7-etapes-du-developpement-produit-une-analogie-avec-les-phases-de-construction/

Episode Transcript

(00:00):
En mode traditionnel, en mode waterfall, mais c'est là que les
correctifs vont apparaître, les fameuses demandes de changement.
Je parlais au début de l'épisode, c'est que Ben Ah, je
pensais que ça marchait de même.Ben pas nécessairement, ça peut
avoir été interprété par de différemment de un de 2.
Ben des fois on pensait pas que les interconnexions entre les
différents morceaux fonctionnentde manière a ou B ou C Ben il
faut corriger le dire fait que on on tombe avec une panoplie de

(00:22):
10 correctifs. Si je reviens, ça clique encore.
Ben le nombre de correctifs, je veux dire, ils ont déployé, mais
le nombre de ça prend combien detemps à ce que le système soit
vraiment 100%? Rationnel, ça a été vraiment
long alors que, mettons à waterfall, mais la maintenance,
Ben, de Sprint en sprint, quand on livre quelque chose, on a la
chance de suite avoir feedback de dire Ah je pensais pas que ça
allait marcher ensemble ces 2 affaires là on peut tu s'assurer

(00:45):
d'harmoniser le tout? Ah OK bon, on va faire un petit
correctif au fur et à mesure fait que oui, c'est un peu plus
de de temps ou de de d'efforts au niveau du projet, mais on est
plus, on se rapproche plus du bouzin à chaque fois que de dire
je vais lancer un d'or sur dans le jeu d'or, puis je vais pogner
le bonheur en patate. Je crois qu'on a pas
d'expérience en plus. Bien nous.

(01:12):
Podcast pivot mon nom est Jonathan Léveillé, président
d'open mind technologies. Le Podcast pivot est distribué
chaque semaine afin d'inspirer et d'éduquer les entrepreneurs
ayant une idée de produit technologique innovante,
communément appelée SAS, plateforme web, application web
ou mobile et qui désire maximiser leurs chances de
succès dans l'aventure. Nous partageons trucs, astuces,

(01:33):
histoire à succès ainsi que des apprentissages d'échecs
d'entrepreneurs de renom. Le Podcast pivot est une
présentation de dev to seeo.com,filiale d'Open mind technologies
DEV. Le chiffre 2 ceo.com aide
exclusivement les entrepreneurs ambitieux qui désirent

(01:54):
développer leur idée d'application logicielle afin
d'en faire un succès d'envergure.
Éric Beaulieu, TEAM Lead développeur senior chez open
mind bienvenue Éric à nouveau sur le podcast un plaisir de te
recevoir encore aujourd'hui, comment vas-tu?

(02:16):
Ça va super bien, et toi? Ça va numéro un super content
d'enregistrer ça avec. Aujourd'hui, on va enfin
démystifier les 7 étapes d'un développement logiciel.
On le sait que pour des gens quise connaissent pas le domaine ou
qui sont exemple des clients ou des prospects, c'est difficile
de comprendre les différentes étapes de qu'est ce qu'on fait
de la Poutine technique de notrecôté, si c'est du jus, du du

(02:40):
jargon qui est difficile à comprendre ou à démystifier, Ben
on a trouvé un moyen aujourd'huide vous transmettre un peu les 7
grandes étapes d'un développement logiciel et de la
manière qu'on va le transmettre.C'est de le comparer à la
construction d'un immeuble, doncon va ramener ça vraiment dans
un langage qui est beaucoup plusfacile à comprendre pour
quelqu'un qui est pas technique.Et le but c'est vraiment de vous

(03:01):
expliquer là les 7 différentes étapes principales et qui vont
permettre de partir de 0 jusqu'àla fin d'un développement
logiciel, toujours en comparant avec la construction d'un
immeuble et également en avant. Un petit peu plus en détail en
comparant la méthode waterfall versus la méthode agile, la
méthode d'agilité. On applique ici chez OPEN mind

(03:23):
pour puissiez bien comprendre les anciennes, l'ancienne
méthode de fonctionnement qui est waterfall versus les
nouvelles. Je fais des références à
quelques épisodes. Ben Premièrement je recule d'un
pas. Si vous êtes visuel, allez
chercher sur notre site l'outil qu'on qui va vous permettre de
suivre ce qu'on va parler d'aujourd'hui.
Les 7 étapes d'un développement logiciel c'est disponible au

(03:45):
triplew.openmind.com slash, le chiffre, 7 tiret étape avec 1S
tiret développement, pas de s, tiret logiciel, pas de s.
C'est disponible dans les notes de l'épisode aussi pour se
rendre directement sur le site web pour aller télécharger le
petit outil 1PDF, une page qui va vous permettre de suivre

(04:05):
visuellement que ce qu'on dit aujourd'hui.
Je fais également quelques références à d'autres épisodes
qui peut vous intéresser en lienavec l'épisode qu'on enregistre
aujourd'hui. On est rendu avec vraiment
beaucoup de contenu, d'enregistrer, donc je vais vous
en présenter plus qu'une aujourd'hui puisqu'un épisode.
Et le premier c'est on va parlerà la fin entre de la maintenance

(04:25):
logicielle, c'est quoi? On a eu la chance de tourner une
excellente épisode avec Éric qu'on a nommé.
Qu'est-ce que la maintenance logicielle?
Les avantages et les concepts expliqués en détail donc,
épisode 29 que vous allez voir. On va parler également un petit
peu des besoins que les clients ont donc l'épisode qui a été
tourné avec Christine sur développer avec ou sans Brother

(04:46):
coller sa solution logicielle donc super intéressant, ça va
relier à ce qu'on parle aujourd'hui.
Épisode 65, on parle de des déploiements et du lexique
épisode 67, petits guides pour les développeurs de comment
réussir son déploiement? Avec Olivier qui est avec nous
ici dans l'équipe. Et dans l'épisode présent, on va
parler d'agilité. Donc on vous réfère épisode 22,

(05:07):
25 et 27 qu'on démystifie le concept d'agilité en comparaison
entre autres avec la méthode waterfall qu'on va parler
aujourd'hui. Et on va parler également de
l'épisode numéro 15 qui est la règle du 20 30 50 et l'épisode
10 qui est la loi de Mc Connell pour les fameux bugs et dans les
logiciels donc, on vous invite àvous référer à ces épisodes là

(05:29):
après l'écoute de celui-ci. Ça va vous aider à mieux
comprendre ce qu'on fait et à maximiser chaque dollar que vous
mettez dans vos investissements de.
Développement logiciel. Éric, avant qu'on avance avec
les 7 étapes, je veux juste que,en quelques mots, on explique la
différence entre un projet en méthodologie waterfall versus
agilité. Parce qu'on va s'y référer

(05:50):
constamment. Et si les gens ont pas eu la
chance d'écouter les épisodes 22, 25 et 27, je pense.
C'est important qu'on mette un petit peu la table.
La différence entre? La méthodologie waterfall est
agitée en quelques mots, Éric. Oui Ben la méthodologie Warfare
ça dit, c'est étape par étape etles étapes une à une sont
emboîtées dans l'autre, ce qui veut dire que on va.

(06:10):
Les 7 étapes qu'on va prendre aujourd'hui, ils vont vraiment
être emboîtés. Puis on recule pas, on fait
juste avancer, avancer, avancer,on corrige pas le tir en cours
de route alors que l'inverse, avec l'agilité, on va toujours
essayer de faire des loupes de de rétroaction feedback pour
aller chercher le meilleur produit qui qui répond aux
meilleurs besoins du client. Par exemple, alors que Waterfall
je reviens. Ben on va faire le cahier de

(06:32):
charge, on va s'assurer que toutest conforme, puis on l'a une
solution et on l'on tombe dans les demandes de changement
interminables. Et c'est là que les extras
par-dessus extra par-dessus extra arrivent.
On le voit dans les projets de construction.
Souvent les projets sont faits en mode waterfall.
Ils le savent sur le terrain quiva avoir une problématique à la
fin, mais c'était pas dans le devis.

(06:52):
Donc là faut ouvrir des demandesd'extra, puis charger des extras
ou arriver à la fin, puis redéfaire ce qu'on a fait en
extra. Qui là coûte vraiment une
fortune donc. À éviter le plus possible donc.
On débute avec les 7 étapes. La première étape éthique, ça
serait numéro un de la planification.
Éric. Ben pour prendre ton adhésion au
moment de la conception, la planification, grosso modo,

(07:14):
c'est trouver où est-ce qu'on vaconstruire la maison, c'est de
dire OK, Ben j'ai trouvé un terrain ABC, puis on va
planifier en conséquence de où est-ce qu'on va mettre la la, la
maison ou l'immeuble dans cette dans dans ce en mode waterfall,
Ben principalement on va. Ça va être d'identifier des
besoins à haut niveau, de définir des objectifs, de
définir tout ce qui va être, mettons matériel qui va être

(07:36):
requis pour le pour le projet avec si certains auditeurs
connaissent les normes I 3. Qui est très connu dans le monde
de développement logiciel. Mais on va faire un document de
vision qui va donner la vision du projet, puis après avoir un
document d'exigence logicielle qui va gratter un peu plus
profond en un peu plus en profondeur sur.

(07:56):
Ce qui est besoin, ce qu'on a besoin, alors qu'en agilité on
va s'asseoir avec le client, on va, on va de suite identifier
rapidement c'est quoi le premierbesoin, c'est quoi la première
chose le plus important. Par après on va y aller, on va y
aller de même, on va identifier vraiment ce qui est prioritaire,
c'est comme ça, on va être capable de construire un bon
backlog pour être capable de dire Ben ça c'est plus
prioritaire que ça et on on l'attaque tout.

(08:18):
Donc ça, c'est la première étape, la planification, donc
trouver le site où construire lamaison. 2e étape, l'analyse des
besoins. Éric.
Oui, l'analyse a besoin. Grosso modo, c'est tu vas
t'asseoir avec l'entrepreneur, l'entrepreneur, tu l'as trouvé?
Tu dis, Hey, je veux faire continuer ma maison, je te veux
toi, Ben. On va, on va, on va s'asseoir
ensemble, on va dire OK, Ben selon tes plans, selon ce que

(08:39):
t'as déterminé, selon ton devis,comme on dit tantôt, Ben je
pense que ça va coûter de même. Je pense que on va y arriver,
mais il va juste s'assurer de s'assurer que les besoins sont
toutes couverts. Alors fait que si on vient
Waterfall, Ben ça va être vraiment d'être une exigence
hyper détaillée ça. Un cahier de charges grosso
modo, qui va être extrêmement précis, extrêmement exhaustif
sur comment que le projet doit être fait de A à Z alors qu'en

(09:02):
agilité, mais vu qu'on attaque des priorités, est ce qu'on a
des hypothèses en partant? Mais on va vraiment juste
détailler certaines des premières fonctionnalités à.
À vérifier. Puis on va construire le cahier
de charge au fur et à mesure. En réalité, le backlog va
devenir à lui même le cahier de charge, mais qui est itératif.
Et si je me mets dans les souliers du client aujourd'hui,
je me dirais, Ben, c'est bien mieux.

(09:23):
La méthode waterfall de tout lister en détail de A à Z pour
que tout soit vraiment bien défini.
La vraie réalité sur le terrain,c'est pas vraiment comme ça, ça
se passe à un développement logiciel et en un sens, un
processus de découverte. Des fois beaucoup du côté du
client parce que les clients viennent nous voir, puis ils me
disent j'ai j'ai un besoin X et quand on se met à avancer avec

(09:45):
lui, à creuser le besoin Y ou Z,puis quand que finalement on
fait bien les devoirs, puis on parle aux usagers finaux qui
vont utiliser le logiciel. Le besoin est complètement
différent. Donc si on avait construit un
énorme cahier de charges avec toutes les petites détails que
le demandeur initial avait en tête, souvent on va livrer la
propriété, on va livrer l'immeuble et finalement y a la

(10:08):
moitié de l'immeuble qui est pasutilisé ou qui est mal construit
pour l'utilisation finale. Donc c'est un peu ça la
problématique, ça semble peut-être plus.
Pertinent, le côté waterfall à cette étape là.
Mais le problème, c'est qu'il y a tellement d'intervenants
impliqués que l'agilité va venirapporter une valeur supérieure
pour venir vraiment répondre auxvrais besoins et aux vrais
exigences sur le terrain et non aux exigences que la première

(10:31):
personne avait en tête. C'est la personne qui vient nous
voir initialement, pense toujours qui est là, la,
l'absolue vérité et moi même pour moi nous-mêmes, avoir fait
des développements logiciels surmesure pour nous à l'interne,
puis c'était moi qui le drivait en arrière, j'étais convaincu
avoir l'absolue vérité. Et finalement quand ça tombe en
utilisation, tu te rends compte que mon Dieu, OK, il aurait
fallu mettre un peu plus d'agilité, puis impliquer un

(10:52):
petit peu plus les utilisateurs finaux dans le développement du
système. Et c'est ce que l'agilité va
apporter et c'est ce qui va créer plus de valeur au final.
L'important c'est pas de suivre à 100% le plan qui est la
première personne pense qui est la vérité.
Mais c'est plutôt de livrer de la valeur aux usagers en continu
pour vraiment créer un retour sur investissement sur le
développement qui était. Donc.

(11:13):
C'est un petit peu la différenceentre le côté waterfall versus
l'agilité. 3e étape, Éric, on tomberait sur le côté
conception. Ouais mais là on a des besoins,
c'est hyper hyper détaillé, on ale plan de la maison de safaga,
mais là ça veut dire que Ben il y a une phase d'acceptation dans
le sens que on va. L'architecte a dessiné des des

(11:34):
plans mais le client il a pas encore vu, mais là il va les
présenter aux clients, il va s'assurer que c'est correct.
Puis on va opter des start-ups de faire du genre dire Ah la
pièce je pensais que c'est plus gros ou la petite pièce je vais
je vais la mettre plus petite ainsi de suite fait que si je
compare au mode au monde du Waterfall, Ben c'est vraiment
encore plus. On on on creuse encore de plus
en plus en détails et on laisse vraiment place à aucun détail,

(11:55):
aucun. Flou dans toute l'architecture
fait qu'on sait exactement quasiment à la virgule près ce
qui va être fait alors que dans mon agile comme tu dis tantôt.
Il y a des hypothèses, il y a des choses à vérifier, on n'est
pas sûr, on est, on s'accorde ledroit de d'avoir vérifié les
choses. Ben en en conception, bon, on va

(12:16):
essayer des choses, on va monterune maquette, on va faire
peut-être des preuves de concepts pour arriver à juste
vérifier avec l'utilisateur. Est-ce que ça fait vraiment ce
que ça pense que ça devait fairetout simplement?
Et c'est là qu'on arrive à la fameuse étape numéro 4 qui est
la programmation qui tout le monde pense qu'on débute par ça
et qu'il faut mettre tout l'argent et tout le temps-là
dedans. La réalité c'est cette étape là,

(12:38):
elle est extrêmement importante,mais ça représente à peu près la
moitié de notre travail. On pourra revenir un petit peu
plus tard avec combien de temps est passé dans chacune des
étapes. Mais c'est comme construire un
building si on fait juste envoyer un paquet de gens
techniques sur le chantier qui sont capables de sortir les les
clous et le marteau, puis les outils, mais qui a pas eu une
bonne planification avant? Et si peur qu'il va avoir un

(13:00):
problème avec l'immeuble au final.
Et là on est rendu à cette date là, c'est de construire
l'immeuble, donc la constructionde la propriété qui est l'étape
de notre côté de la programmation, Éric.
Ben la grosse différence entre les 2, entre les 2 méthodes
cette fois-ci, c'est vraiment laquantité de code ou la quantité
de de de de livres qui va être fait à waterfall.
On va livrer l'intégralité ou quasi l'intégralité du projet

(13:21):
One shot. C'est comme si on donne une
grosse fusée tout d'un coup alors que Ben en mode agile.
Mais on va mettre les on va s'assurer que les pièces une par
une de la fusée. Sont corrects, sont à la bonne
place, font bien la bonne, la bonne job ainsi de suite.
Puis si des choses qui sont qui sont pas bonnes ou qui ont mal
été mises ensemble, Ben on a le droit de revenir puis de
corriger le tir pour avancer. C'est ça la grosse différence.

(13:46):
Et si on vient le comparer à ce moment-là, une propriété, on
pourrait penser à un building dans lequel votre votre
compagnie opère, mais au lieu deconstruire tout le building et
dire joue un Bienvenue dans votre nouveau building, puis là
vous Découvrez que la cuisine est pas assez grande, que le le
frigidaire est pas à bonne place, que les toilettes sont
mal positionnées, sont trop petites.
Et la réalité c'est qu'on on vous livre à ce moment-là la

(14:07):
l'entrée du building. Après ça on va vous livrer les
salles de bain, ensuite on va vous livrer la cuisine si vous
avez la chance de les tester vous dit Ah Ben là je pensais
pas que ça avait l'air de. On peut être j'ai oublié quelque
chose, j'ai oublié de vous mentionner quelque chose.
On peut itérer au lieu d'arriveravec un paquet de non-conformité
à la fin, puis que là le le client est pas content.
On va adresser étape par étape pour venir éviter de créer des

(14:27):
effets boule de neige sur les problématiques qui peuvent être
découvertes en cours de route. Ce qui nous amène à la 5e étape
qui est extrêmement importante, les tests.
Oui, mais au monde du dans le monde du bâtiment, grosso modo,
c'est l'inspecteur en bâtiment qui se promène en dans la
bâtisse en mode waterfall. C'est comme si l'inspecteur
allait juste à la fin puis vérifiait toutes.
Ah tout est correct, tout est donc conforme au code, tout est

(14:48):
correct, mais l'affaire c'est qu'il rouvre pour aimer, il
jette pas le courage des prises électriques et il vérifie pas,
mettons les lampes, les Lumièressont bien installées alors qu'en
mode agile, en mode scrum, vu que on a une rétroaction à
chaque itération qu'on livre. Ben on va l'inspecteur, c'est
comme s'il était là tout le temps.
Fait qu'au fur et à mesure qu'onfait des morceaux, au fur à
mesure qu'on avance les pièces une par une, Ben l'inspecteur

(15:11):
lui il dit Ah je pense que ça fait pas de sens.
Ah je pense que ça fait pas de sens ça avec ça.
Pas sûr. C'est une bonne idée fait qu'il
vérifie tout ça ensemble, fait que l'intégralité du projet est
là, mais il évalue au fur et à mesure que maintenant il voit
les interconnexions entre les morceaux.
Donc super intéressant. Le côté test, le côté assurance
qualité, le niveau. L'agilité permet d'en faire plus

(15:34):
fréquemment corriger le tir pours'assurer de ne pas accumuler un
paquet de non-conformité à la fin, ce qui maximise
l'utilisation du budget puis la valeur livrée.
Là c'est bien beau que la bâtisse elle est construite mais
faut la livrer au client et il faut qu'il commence à
l'utiliser. Donc le numéro 6 de notre côté
c'est le déploiement de l'application donc ça serait la
remise des clés au propriétaire et l'emménagement dans la

(15:54):
propriété. Oui, Ben en waterfall.
Ben je veux dire, comme ça, s'entoure.
Ben, on donne le chef, vas-y, amuse-toi avec.
Euh, je pense, un petit projet qui a qui a un marché de même
récemment, ça clique, on le connaît toutes.
Euh mais c'est comme ça qui a été faite, les utilisateurs ont
pas été formés. Les le monde se sont dit, Ben on
pense qu'ils vont l'utiliser de la bonne manière.

(16:16):
Ben c'est malheureusement, c'estun des un des principes du
waterfall alors qu'en agilité. Mais vu qu'on a livré le morceau
par morceau, on a pu tester avecles différents auteurs les Power
users qu'on qu'on connaît souvent aussi.
Ben on s'assure que le monde déjà le savent à l'avance.
Puis ils deviennent même des formateurs à l'interne pour que
les autres personnes puissent l'utiliser.
C'est ça qui est vraiment très important.

(16:36):
Et on parle du fiasco de sa clique.
On a dans notre backlog d'idées de d'épisode à tourner, de de
décortiquer ce qui s'est passé et d'émettre des
recommandations. C'est toujours plus facile de le
faire après par contre. Mais quand même y a des choses
que nous on recommande dans nos développements pour essayer
d'éviter ce genre de cas-là. Donc si jamais ça vous intéresse
qu'on priorise cette cet épisodelà, venez nous écrire sur

(16:58):
LinkedIn faite nous envoyer un petit mot qui un petit petit mot
clé sa clique et on va le prioriser à ce moment-là dans
nos épisodes à tourner devant nous je pense.
C'est un bon cas. À faire un un post mortem et et
les postes mortels? On est des grands fervents ici
chez OPEN minded OCO de d'enfer pour apprendre de nos erreurs et
devenir toujours meilleurs. Donc hésitez pas à nous écrire
si c'est un sujet qui vous intéresse, ça nous amène sur le

(17:21):
la dernière étape donc la personne a aménagé dans
l'immeuble mais il reste encore du travail dans le fond à faire
par après il y a de la maintenance à faire au niveau de
l'immeuble pour la garder fonctionnelle, la garder en vie,
la garder la valeur de l'immeuble et la fonctionnalité
de l'immeuble. Donc on ramène au développement
logiciel, c'est une étape de. Maintenance, Éric.

(17:41):
Ben en mode traditionnel, en mode waterfall, mais c'est là
que les correctifs vont apparaître, les fameuses
demandes de changement. Je parlais au début de
l'épisode, c'est que Ben Ah, je pensais que ça marchait de même.
Ben pas nécessairement, ça peut avoir été interprété par de
différemment de un de 2. Ben des fois on pensait pas que
les interconnexions entre les différents morceaux fonctionnent
de manière a ou B ou C Ben il faut corriger di fait que on on

(18:03):
tombe avec une panoplie de dits correctifs.
Si je reviens à ça, clique encore.
Ben le nombre de correctifs, je veux dire, ils ont déployé, mais
le nombre de ça a pris combien de temps à ce que le système
soit vraiment 100%? Naturel, ça a été vraiment long
alors que, mettons à waterfall, mais la maintenance, Ben de
Sprint en sprint quand on livre quelque chose, mais on a la
chance de suite avoir feedback de dire Ah je pensais pas que ça

(18:24):
allait marcher ensemble ces 2 affaires là on peut tu s'assurer
d'harmoniser le tout? Ah OK Ben on va faire un petit
correctif au fur et à mesure fait que oui, c'est un peu plus
de de temps ou de de d'effort auniveau du projet, mais on on est
plus, on se rapproche plus du bouzin à chaque fois que de dire
je vais lancer un d'or sur dans le jeu d'or, puis je vais pogner

(18:44):
le boule d'or en patent. Pas sûr, c'est pas qu'on a pas
d'expérience en plus. Effectivement.
Donc si je résume, on a 7 étapes, on le ramène encore au
niveau de la construction. Donc la première étape d'une
construction c'est de trouver lesite pour construire la maison
en développement logiciel, c'estla planification de notre côté.
2e étape, on rencontre l'architecte où l'entrepreneur.

(19:05):
De notre côté, c'est de l'analyse de besoins. 3e étape,
on a la présentation du plan de la maison par l'architecte avec
des corrections à faire en avançant, donc c'est la
conception. De notre côté, on construit la
maison, donc la programmation. Ensuite, il y a des il y a
l'inspecteur en bâtiment qui s'assure que tout est conforme
au code du bâtiment, donc c'est les tests.

(19:26):
De notre côté, on remet les clésau propriétaire, on emménage
dans la maison. C'est l'étape numéro 6 du
déploiement et on termine ensuite avec les petites
corrections à faire dans l'immeuble, les petits
ajustements et l'entretien de l'immeuble.
Donc on parle de la maintenance au niveau logiciel.
Donc voilà, ça compare exactement un développement
logiciel à au développement d'une propriété.

(19:48):
Ma dernière question, Éric, qu'on pourrait peut-être aborder
ici, qui se retrouve également dans l'outil que je parle en
ligne initialement avec le nez dans les notes de l'épisode,
j'entends les gens se poser la question, c'est bien beau que
cette étape, cette étape, mais c'est quoi le pourcentage de
temps moyen qui devrait être alloué par étape, juste pour en
avoir une vue à haut niveau? Donc je vais poser la question,

(20:09):
Éric, pour l'étape de planification, analyse de
besoins, conception, donc les 3 premières étapes.
C'est quoi les pourcentages? À peu près tant d'un projet qui
devrait être alloué dans ces étapes là en méthode agile.
Mais c'est absolument. C'est un classique, ça dépend
comme dans tout le développementlogiciel, mais selon les
statistiques, selon notre expérience habituelle, mettons

(20:29):
la planification, grosso modo, on va y accorder, mettons 5% du
temps du projet, mais on va, on va le mettre au fur et à mesure
en mode agile à au lieu que de le faire tout d'un coup au
niveau de l'analyse de besoin, au niveau de de raffiner ces
besoins là grosso modo 8%, puis la conception pour compléter,
faire un beau, un beau corps, mais ça fait 12% si on

(20:51):
additionne les 3 premiers 25% duprojet.
Dans les 3 premières étapes. Donc avant même de développer
une ligne de code, on parle de 1/4 du temps, 1/4 du budget à ce
moment-là de développement et c'est là, souvent les clients
veulent tourner les coins ronds.Et ça coûte cher de tourner les
coins ronds à cette étape là, parce que c'est ce qui va faire

(21:11):
que la programmation va coûter le double, le triple ou le
quadruple. Donc ne négligez pas, c'est
comme bâtir une propriété ou un immeuble.
Ça serait inimaginable de pas faire des bons plans
d'architecte, puis de pas faire des bons plans au niveau de la
ventilation, au niveau de l'électricité, de Challenger ces
plans là, des réfléchir, de tourner tout bord tout côté.
Donc c'est un peu la même chose.Il y a des sous à mettre avant

(21:33):
de sortir la fameuse expression du gona clou sur le chantier.
C'est la même chose avec un développement logiciel.
Ensuite, on tombe sur les tablesde programmation, les tables de
test, les tables de déploiement.C'est quoi les pourcentages
qu'on peut voir en moyenne là grosso modo?
Ben comme tu dis tant au de la condition de la maison.
Ben principalement c'est vraiment le cœur du du projet.

(21:54):
Puis les tests avec l'inspecteuren bâtiment si je si je mets la
programmation des tests ensembleça fait 60% d'un côté c'est 45,
de l'autre côté 5 15 additionne l'ensemble qui fait 60% on voit.
C'est vraiment là que le que le la majorité du budget est
investie. Puis mettons au déploiement,
mais la, la la boucle. Mais on dit environ 10% parce
que là il y a des allers-retours, des correctifs

(22:16):
et que ça fait plusieurs déploiements.
Qu'on le pouvoir dans les autresépisodes.
Ben oui, c'est un temps à pas sous-estimer.
Ce qui nous resterait l'étape dela maintenance.
On parle qui nous restait environ un 5% donc j'imagine 5%
c'est dans la première année du développement logiciel.
Par la suite y a de l'évolution à faire au niveau du logiciel
d'optimisation, rajouter des fonctionnalités que le budget

(22:36):
généralement juste en maintenance, stabilisation au
niveau de la sécurité au niveau de la de la des fonctionnalités
pour que ce soit fonctionnel et des petites optimisations de
base. On parle d'un 5 des fois 10 15%
selon à quel point le logiciel devient vieux à travers le
temps. C'est comme une propriété plus
le logiciel prend de l'âge. Plus faut y porter de

(22:57):
l'attention pour le garder fonctionnel entre autres.
On en parle beaucoup dans l'épisode de maintenance que
j'ai fait et référence au début du podcast.
C'est très flou pour les clientscette étape là de maintenance.
Prenez le temps d'aller écouter l'épisode on vraiment de
décortiquer chacun des points del'importance et des sous étapes
de maintenance, entre autres la partie sécurité et la partie

(23:19):
fonctionnelle. Qu'on pense qu'on développe un
logiciel puis c'est magique. Il y aura pas de problème de
sécurité, il y aura pas de problème de fonctionnalité à
travers le temps. Malheureusement, c'est un
écosystème avec beaucoup de choses qui qui changent autour
des lignes de code qui vient impacter à ce moment-là le
système en tant que tel. Donc aller écouter cet épisode.
Éric, dernier petit mot avant qu'on termine le podcast?

(23:39):
Ben si je peux combiner avec la maintenance par rapport au monde
de l'immeuble. Vous souvenez des températures
il y a 40 ans au Québec? Les températures d'aujourd'hui,
les le code de la maison il y a 40 ans, le code de la maison
aujourd'hui était pas fait pour supporter les mêmes températures
que dans ce temps-là. Les vents étaient pareils, la
neige était pas pareil cette tu sais, y avait dans le temps eu
du verglas. Le dépanner salopette
aujourd'hui c'est pas ça. En conséquence fait que penser à

(24:02):
la maintenance comme au nom de l'immeuble dans ce sens-là?
Et surtout pour préserver sa valeur.
Souvent les gens vont dire bon, je mets un bon montant cette
année pour développer le logiciel et je pense qu'il faut
que je mette 0 dans les années suivantes.
La réalité c'est que si ça a bien été planifié, le
développement logiciel il devrait avoir un retour sur
investissement sur ces dollars mis la première année.
Mais pour préserver cet avantagelà sur la compétition et cette

(24:24):
efficacité là que vous avez créée avec votre développement
logiciel, il faut mettre un peu de sous d'entretien parce que
c'est pas vrai que c'est magique.
Puis c'est pas vrai que ça va fonctionner toujours
parfaitement. Aller écouter l'épisode de
maintenance, allez comprendre plus en détail.
Pourquoi il y a une importance sur la section de la
maintenance? Je me répète, Éric, un dernier
petit quelque chose à rajouter avant la fin de cet épisode?

(24:44):
Non, je pense qu'on a vraiment bouclé la boucle aujourd'hui.
Fantastique et je vous invite à les télécharger sur le site web
qui est l'adresse dans les notesde l'épisode de petit outil
visuel qui peut vous aider pour vous et même pour expliquer le
tout à votre équipe dans votre organisation.
Si vous pensez faire un développement logiciel, ça va
aider à conceptualiser les différentes étapes.
Et on a souvent le l'expression chez open mind de dire que faire

(25:08):
un développement logiciel avec un client, c'est la même chose
que d'aller gagner une compétition de danse.
Donc on va être aussi bon que notre capacité à élever le
partenaire avec qui qu'on va danser.
Donc vous qui est de l'autre côté du Podcast.
Donc notre but c'est d'élever votre connaissance pour
s'assurer que chaque dollar que vous pouvez mettre avec un
partenaire tel que open mind to SEO va vraiment donner une

(25:32):
rentabilité et va aider à vous rendre plus rentable, plus
efficace dans votre organisation.
Donc la connaissance est extrêmement importante, donc on
vous transmet du data, on vous transmet notre expertise pour
réussir ensemble à les gagner cette fameuse compétition de
danse. Donc Éric, merci encore
aujourd'hui pour toute cette belle préparation et ce beau
podcast là, en espérant que ça vous intéresse.

(25:53):
Vous avez d'autres types d'épisodes ou des idées que vous
avez en tête? N'hésitez pas à venir nous
rejoindre nous parler sur LinkedIn on on parle avec
plusieurs d'entre vous à chaque semaine, j'ai des belles
discussions extrêmement intéressantes et n'oubliez pas,
on produit ce contenu là gratuitement pour vous avec
amour et beaucoup d'efforts. On vous demande juste une seule
chose, mettez ce podcast là sur pause, prenez 17 secondes de

(26:17):
votre vie. Pour aller mettre un 5 étoiles
sur les plateformes de balado préférées que vous utilisez,
c'est tout ce qu'on vous demande.
Ça fait toute une différence pour nous.
On vous remercie et je vous dis à bientôt.