17 - Une application de A à Z : besoins, code, tests et production | Le Dernier Clic (avant la fin du monde)

Description

Un épisode un peu à part, dans la continuité de celui sur notre portail. Cette fois, on quitte notre propre cas pour dérouler le chemin complet derrière n'importe quel logiciel, du premier besoin jusqu'à la maintenance. L'idée part d'un constat simple. À force d'entendre qu'avec l'IA on sort une application juste en promptant, on oublie tout ce que fabriquer un produit demande vraiment. Alors on pose le vocabulaire et les grandes étapes, celles par lesquelles on passe qu'on soit client d'un éditeur, en discussion avec un dev, ou soi-même tenté de se lancer en vibe coding.

Plutôt que de tout détailler, on suit le même fil d'un bout à l'autre : sur un logiciel, on gagne presque toujours à réfléchir avant de coder, et à découper pour ne pas tout casser au premier changement. Deux images reviennent pour le rendre concret. Celle de l'architecte, qui pose ses plans avant de monter les murs. Et celle du document qu'on écrit à plusieurs, qui sert à expliquer Git et GitHub, ces mots qu'on croise partout avec le vibe coding sans toujours savoir ce qu'ils recouvrent. Le recueil des besoins et les tests prennent le plus de place, ces derniers avec leurs familles et la dette technique qui s'installe quand on va trop vite. Et comme le sujet parle surtout à celles et ceux qui se lancent avec l'IA, on ramène chaque étape à leur pratique. La suite, elle, montrera concrètement le développement de notre portail.

Git
Formation Git
Github

00:12 - À l'ère du vibe coding, tout le chemin derrière un logiciel

04:40 - Le recueil des besoins : métiers, existant, fonctionnel et non-fonctionnel

20:47 - Conception : PRD, user stories et le découpage en briques

30:40 - Développement et versionnage : Git, GitHub, branches et pull requests

44:47 - Les familles de tests, la dette technique et les refontes

1:14:03 - Mise en production, maintenance et modèles de développement

Retrouvez nous sur :

https://www.instagram.com/ledernierclic/

https://www.linkedin.com/in/emmanuel-fernandez-b28740180/

https://www.linkedin.com/in/lucile-mothiron/

contact@ledernierclic.fr

Hébergé par Ausha. Visitez ausha.co/politique-de-confidentialite pour plus d'informations.

Transcription

Manu
Bonjour et bienvenue dans Le Dernier Clic, votre podcast tech, IA et no-code. On se retrouve comme chaque semaine avec Lulu. Comment ça va ?
Lulu
Ça va bien.
Manu
Et d'ailleurs, je ne te m'en ai pas demandé s'il ne faisait pas trop chaud chez toi. Tu n'étais pas encore en mode caniculaire.
Lulu
Oui, je suis venue, c'est signé. comme toujours, mais bon, on arrive à garder du frais à la maison, donc ça va.
Manu
Parfait. Alors, on se retrouve cette semaine pour changer un petit peu des sujets d'IA, parce qu'on vous a pas mal parlé d'IA ces dernières semaines et ces derniers épisodes, notamment sur l'IA frugale et la semaine dernière quand on vous a parlé également de notre portail. Donc, on est revenu en fait un petit peu sur ce que ça implique de développer une application en l'illustrant à travers le développement de notre application, de notre portail qu'on utilise, nous, au quotidien maintenant pour préparer nos épisodes. C'était un épisode côté outils un petit peu thématique et un peu plus particulier. Je vous invite à l'écouter si ce n'est pas déjà fait et si le sujet vous intéresse. Et aujourd'hui, histoire de faire le pont justement avec tout ça et de clarifier un petit peu ce que représente le développement logiciel, le développement d'une application au sens un peu plus général. qui n'est pas spécifique au wipecoding et au développement assisté par IA, qui n'est pas spécifique non plus à la manière dont nous, on travaille avec Lulu et ce qu'on vous a présenté la semaine dernière et ce qu'on continuera de vous présenter la semaine prochaine. Là, l'idée va être de revenir un petit peu sur le développement logiciel au sens large. Lulu, je te laisse nous dire un petit peu pourquoi aussi on part sur ce sujet-là maintenant.
Lulu
En fait, on s'était dit... Peut-être qu'on continuera juste à parler du développement dans cet épisode-là, mais moi, en tout cas, ça me semblait important de juste prendre le temps de définir les différentes étapes et de revenir un peu sur le vocabulaire aussi. Parce que c'est peut-être des expressions qu'on voit beaucoup dans notre bulle, mais sans forcément comprendre ce que ça implique de faire des tests, sachant qu'il y a différents tests, même les différents types de développement. Bon, là, on n'ira pas. pas beaucoup dessus. On a essayé de condenser pour donner un vernis et une première couche de vocabulaire et savoir ce que ça veut dire quand une application est en prod, le côté maintenance, vraiment toutes les grandes étapes de développement. On est dans de la vulgarisation, on sait que c'est différent plus ou moins dans chaque boîte, mais là, c'est des grandes étapes. dans la théorie et a priori, on passe par celle-là.
Manu
Oui, on va effectivement, on va revenir vraiment sur les principes et que vous soyez exposé en fait déjà ou pas au jargon et à certains mots qu'on emploiera. L'objectif là justement, c'est que ce soit clair pour tout le monde. Parce que bien souvent, quand on croise des gens dans les boîtes, même si votre entreprise est un éditeur de logiciels et qu'elle va le mettre à disposition de clients pour une fonction Voilà. pour un usage spécifique ou des usages spécifiques, au sein d'une entreprise, il est quand même assez fréquent de voir que les gens ne se rendent pas forcément compte de ce qui se passe dans les autres services et du rôle de chacun et du rôle de chaque équipe au niveau d'un produit, au niveau d'un logiciel. Donc on n'ira pas justement dans le détail de tout, comme disait Lulu, puisque en fait, en fonction de la taille de l'entreprise, déjà, ça va impacter différemment et avoir des... comment dire... des dépendances et des sujets plus ou moins vastes et des implications techniques plus ou moins vastes. On ne va pas revenir sur tout ça parce que ce serait infini, mais bien vous donner les clés de compréhension de ce qu'est un logiciel, vraiment de bout en bout, en tout cas sur toutes les phases principales et importantes.
Lulu
Ça dépend du type de logiciel aussi qui va être développé. Il y a autant de spécificités presque de logiciels et d'équipes. C'est des grandes phases aussi pour savoir ce que ça implique parce qu'on a l'impression qu'avec l'IA, tout est simple et on peut tout aussi bien se lancer soi-même dans le développement ou passer par quelqu'un qui développera. Et je pense que c'est important d'avoir ce vocabulaire qu'on soit potentiellement client ou une personne qui va se dire « bon, je peux faire un logiciel maintenant juste en comptant » . C'est bien de savoir tout ce que ça implique.
Manu
Parce que typiquement quand vous avez un produit dans les mains, un logiciel dans les mains, il n'y a pas juste eu une étape où vous avez dit je veux tel truc, je veux un programme qui me fasse ces trois fonctions et quatre boutons, et basta, il y a tout un chemin à parcourir pour arriver à deux. du début à la fin. Et le début de ce chemin, en fait, il va passer par ce qu'on appelle le recueil des besoins. On l'avait déjà évoqué la semaine dernière, un petit peu, à travers la compréhension des besoins pour notre cas d'usage qui était le portail. On s'est dit, ben voilà, nous, aujourd'hui, on a des infos éclatées dans plein d'outils, on a besoin de tout centraliser, et que ça nous aide à faire un épisode de tout en bout. Et pour ce faire, ben voilà, que ce soit sur un usage comme le nôtre ou sur n'importe quel usage, vous allez avoir besoin de comprendre et... d'interagir et d'aller chercher les informations pour ce fameux recueil de besoins. Est-ce que tu peux nous l'expliquer un peu, Lulu, sur les différentes approches qu'il peut y avoir, justement ?
Lulu
Oui, et juste aussi, on en avait parlé dans l'épisode sur l'Igafrugal, où déjà de bien définir, savoir si ce qu'on veut développer n'a pas déjà une solution, de bien répondre à un problème, parce que si on se lance tout de suite dans le développement du logiciel, on peut le faire de la meilleure manière possible, s'il ne répond pas. à un problème ou à une douleur, il ne va pas forcément servir et ce sera toutes les étapes derrière qui vont juste partir à la poubelle où le logiciel ne sera pas utilisé. Et c'est important, déjà pour recueillir du besoin, et il faut aller chercher du concret, donc en général, ça passe par des phases de discussion avec des vrais gens qui, idéalement... ont ces problèmes au quotidien, ou des frictions, ou ils connaissent un peu leur process. Alors là, c'est peut-être plus dans un cas de... Comment dire ? Pas que d'outils internes, parce qu'après, je pense que c'est encore différent en startup, quand tu développes un produit. Toi, tu connais peut-être un peu plus du côté là, mais on va avoir des entretiens, on va les observer, étudier l'existant, que ça soit un logiciel déjà existant. ou savoir comment les gens travaillent. Et nous, pour mettre en parallèle, c'était un peu toute notre phase de bricolage, savoir par où passer l'information et qu'on ait un peu une idée des flux. Je ne sais pas si toi, peut-être par rapport à ton expérience...
Manu
Alors, déjà, effectivement, normalement, le besoin d'une application, le besoin d'un logiciel, il l'est habituellement et théoriquement, il émerge tout seul. Il va émerger tout seul d'un problème que... Quelqu'un dans son entourage va rencontrer, et dans son entourage que ce soit perso ou pro, mais disons qu'on est dans un contexte d'entreprise, donc ça va être des collègues qui vont commencer à se plaindre d'avoir besoin de quelque chose pour arriver à leur fin. Pour produire un document, par exemple, de travail, ils n'ont pas les informations qu'il faut, ou alors ces informations, ils sont obligés, comme nous, d'aller les chercher dans 15 endroits différents, ou alors ils n'ont techniquement rien qui leur permette de produire le livrable dont ils ont besoin, que ce soit un document, que ce soit un PDF, que ce soit un... pas importe le livrable final, quelque part, le besoin, il part de là. Et donc ça, c'est une approche de recueillir tout simplement ce qui a été constaté dans une boîte. Donc soit parce que la solution n'existe pas, soit parce que la solution, aujourd'hui, elle a été bricolée. C'est pour ça qu'on a beaucoup de gens qui utilisent du Excel et qui le détournent ou qui utilisent d'autres outils qu'ils ont à disposition dans l'entreprise et qui vont gruger un petit peu comme ils peuvent dans les différents bouts. pour les tordre au mieux et arriver à leur fin. Parce qu'à partir du moment où ils n'ont pas l'outil adapté, il faut quand même réussir à bosser. Et ils vont employer un petit peu tous les moyens à leur disposition pour y arriver. Et après, il y a le contexte d'éditeurs de logiciels ou de startups, peut-être plus propres aux startups ou aux boîtes qui vont démarrer, qui vont identifier un besoin qui n'est pas encore couvert par le marché, soit qui est... partiellement couvert par le marché ou pas de la bonne manière ou alors, parce qu'en fait la plupart des besoins dans les boîtes ils sont là depuis très longtemps, c'est juste la manière d'y répondre qui va être différente et un point de vue, un angle, une façon de le faire, une technologie nouvelle, une interface plus simple enfin voilà, il y a plein de choses pour l'amener, mais qui va être de repenser le problème d'une manière différente. Si on prend des gros outils, pour essayer d'aller dans un peu plus de concret, des suites logicielles comme Word. ont apporté de la bureautique pendant très longtemps à travers le classique éditeur de texte, le tableur et le PowerPoint, l'éditeur de diaporama. Google a un peu renversé tout ça quand il a apporté le collaboratif à l'époque de Google Drive et de la suite Google. Donc d'un coup, on s'est rendu compte qu'on n'avait plus besoin d'installer ces programmes-là sur son ordinateur et que chacun ait sa licence et tout ça pour travailler. Mais on pouvait passer, même s'il y avait aussi un système de licence. mais on pouvait passer directement par des outils en ligne, via internet, sans avoir à rien installer, et quand même avoir du collaboratif où tout le monde travaillait en temps réel sur le même document, on voyait les gens interagir. Et voilà, ça a été une nouvelle façon déjà d'appréhender la suite bureautique avec un aspect neuf. Et Notion, prononcez-le comme vous voulez, l'a apporté encore d'une manière différente plus tard, avec cette idée de partir d'une page blanche, d'avoir un header qui soit beaucoup plus simple qu'un Word, et en même temps d'intégrer dedans des petites bases de données qui ressemblent à des tableaux, donc c'est assez familier pour qu'on les prenne en main. mais où on va être sur des bases de données relationnelles, et du coup chaque tableau, chaque colonne ne sera pas un simple, ne sera pas que du chiffre, sera moins rigide et mieux pensé qu'un Excel, ce ne sont pas les mêmes finalités. Mais vous voyez qu'à travers ces trois exemples, on a trois visions différentes d'une suite bureautique, et qui ont évolué forcément à travers les technologies, et les phases d'évolution, et la prise en main aussi des gens. Peut-être qu'un Notion à l'époque de Microsoft Office n'aurait pas du tout fonctionné parce qu'il aurait été trop avant-gardiste. Il y a aussi toute une logique quand même de répondre à un besoin, mais d'une manière que les gens sont aussi en mesure de s'en saisir et de le prendre en main. D'ailleurs, les premières versions de Notion n'étaient pas bonnes en termes d'expérience utilisateur et ont dû être repensées. Donc généralement, quand vous avez un programme aussi dans les mains, ne vous dites jamais qu'il est arrivé comme ça, tel quel déjà prêt. Il est passé par plein de phases en amont. Au début, c'était probablement une version brouillon, un peu éclatée, que personne ne comprend, avant qu'on identifie ce qui va et ce qui ne va pas dedans, pour que ça arrive à quelque chose de propre et d'agréable à utiliser. Et voilà. Tout ça pour en revenir aux besoins, c'est que ça part justement de quelque chose qui est concret, et qu'on va pouvoir, comme disait Lulu, le peaufiner et mieux l'interpréter, le comprendre, à travers des discussions, les fameuses discussions qu'on appelle avec les métiers. Donc là, ça peut prendre des formes d'atelier métier, d'entretien métier. Le but, c'est de mettre des gens dans la même pièce ou d'interagir et de discuter directement avec des responsables qui font ce boulot au quotidien et qui sont les premiers concernés.
Lulu
Ça ou l'étude de marché aussi ? Si le produit est destiné pas forcément à une entreprise, mais plus à des utilisateurs lambda, on peut... Oui, mais est-ce que... Je ne sais pas si on les appellera des métiers, les gens, si c'est par exemple du SaaS.
Manu
Oui, ça dépend, effectivement. Si tu t'adresses à du particulier ou à de l'entreprise, mais en tout cas, voilà. Il faut discuter avec des gens. C'est ça. À un moment ou à un autre, il faut parler avec des gens qui vont avoir besoin, enfin, celles et ceux pour qui vous voulez créer le produit et répondre aux besoins. Il n'y a pas de meilleur moyen de comprendre leurs problèmes qu'en parlant avec eux. Ou après, il y a des phases d'observation aussi qui peuvent être faites. Donc, typiquement... dans des contextes d'entreprise, d'aller voir un peu comment les gens bossent au quotidien et de se rendre compte qu'ils font du Excel, qu'ils font de tels outils bricolés. Et c'est là qu'on va voir encore davantage les petites failles et comment ils y auront répondu dans l'immédiat et se dire que c'est des pistes de réflexion, de se dire, en fait, il a pensé à sa solution de telle manière, ce qui pourrait sembler complètement pas efficient quand on le voit de l'extérieur, mais du coup, qui va donner des indices sur la manière dont les gens bossent et pensent leur solution. Il va y avoir d'autres approches aussi. Donc, tu l'as dit, la partie études de marché, études de l'existant. Il y a déjà plein de concurrents, il y a plein d'outils. On va mettre les mains dedans. Et d'ailleurs, ça que ce soit dans toutes les logiques produits, et quand on pense des nouvelles fonctionnalités, quand on va améliorer un logiciel, ou le concevoir de toutes pièces aussi, on va forcément mettre les mains dans les logiciels qui se rapprochent le plus sur le marché et voir un peu ce qu'ils proposent et ce qu'ils ne proposent pas. En fait, c'est aussi un des points de compréhension du besoin, de se dire que la plupart des acteurs ont mis en avant tel sujet et telle manière d'y répondre, parce qu'en fait, ils s'adressent, je viens de bêtiser, tous et toutes aux PME et aux grosses boîtes. Mais en fait, ce même problème existe chez les TPE, et personne ne l'a traité aujourd'hui, parce que c'était peut-être trop galère à faire, ou trop compliqué, ou machin, alors qu'il y a un autre angle, alors qu'il y a une autre manière d'envisager le problème.
Lulu
Et ce n'est pas parce qu'on a... un problème, nous, que ça veut dire qu'il faut forcément faire un produit, il faut le confronter, c'est pas forcément une phase agréable parce qu'on va se prendre des retours, ça va potentiellement modifier l'idée qu'on pouvait avoir de notre solution parce qu'on a souvent tendance à penser directement aux solutions de comment notre application, elle, pourra faire, machin, et que au final, des fois, la solution, elle pourrait être beaucoup plus simple, moins waouh, enfin... Et juste d'aller confronter et de se rendre compte que peut-être il y a déjà des solutions qui existent et on peut être tout seul à avoir ce problème. Alors c'est assez rare, mais ça ne vaut pas le coup de sortir tout de suite le développement, de partir à l'étape d'après. C'est presque l'étape-là qui est... la plus importante, alors les autres le sont aussi, mais toutes les autres, aussi bien qu'elles seront exécutées, si la base n'est pas solide, parce que si on définit mal un besoin et qu'on se rend compte finalement qu'il y a telle fonctionnalité, enfin, pas fonctionnelle, parce qu'il y a aussi le côté fonctionnel, non fonctionnel qu'il faut séparer, mais si on se rend compte que finalement il faut qu'on ajuste quelque chose, c'est beaucoup plus facile au stade de découverte et de... pour définir le besoin et les problèmes, qu'au moment où tout est développé, il y a des dépendances, il faut changer du code et potentiellement des choses qui vont coûter très cher. C'est un peu comme passer par un architecte avant de se lancer dans une construction, une grosse rénovation. Il va faire des plans. Peut-être que les plans ne seront pas suivis au millimètre près, mais ça donne déjà une idée de l'ordre d'exécution, de se projeter aussi. Et que si on se dit, ah bah tiens, finalement, je vois... plus ma cloison comme ça, la cloison, on va juste la déplacer un peu dans un logiciel où on gomme et puis on refait notre cloison. Alors qu'une fois que c'est monté et qu'on est là et que tout est fait, on se dit, c'est vrai que ça aurait été bien un peu différemment. C'est pareil dans un logiciel, il ne suffira pas non plus de juste prompter et dire, finalement, mon interface, je la verrai complètement différente qui va faire aussi modifier complètement le back-end. Voilà, c'est important.
Manu
Oui, mais j'aime bien la métaphore, parce qu'effectivement, c'est plus facile de pincer les murs à l'avance que de les monter une fois, se rendre compte que la moitié ne va pas, les casser et les refaire différemment.
Lulu
Surtout quand tu vois toutes les couches qui se rajoutent par-dessus, ou peut-être elle, j'ai fait ta trichoterie, ou c'est comme par exemple de se dire, tiens, dans cette pièce, je veux mes prises ici, Si on ne se dit pas où est-ce qu'on va penser nos meubles, alors ça demande de se projeter pas mal et ce n'est pas ce qu'il y a de plus confortable, ça demande pas mal d'énergie. Mais il faut savoir qu'il y aura toujours des choses qui vont se passer pas comme prévu. Donc tout ce qu'on peut prévoir au départ, ça sera de l'argent et du temps gagné pour après.
Manu
Effectivement. Et à garder en tête qu'en fait, plus tôt vous allez, plus vous avez d'infos au départ, plus les étapes d'après vont être fluides et pertinentes, plus vous bâclez ou vous... Prenez pas le temps de réfléchir vraiment aux besoins initiaux et comment on peut y répondre de la manière la plus simple possible. Comme disait Lulu, plus derrière, vous risquez d'avoir un espèce d'effet qui va se décupler en termes d'efforts, en termes de temps, en termes d'impact et où chaque chose à reprendre sera beaucoup plus galère à faire derrière.
Lulu
En soi, oui, une prise, on peut en rajouter un endroit, mais ça veut dire refaire une saignée potentiellement dans le mur qui est tout propre, qui est tout beau avec... le placo qui est déjà mis, la plomberie, mince, on s'en a saigné, on tape dans un tuyau. Autant imaginer, essayer d'imaginer de se projeter dès le départ, quitte à passer un peu plus de temps. C'est vrai que les personnes techniques ou même les clients ont vite envie de voir quelque chose et d'attaquer le développement, parce que c'est là que le projet commence vraiment. Et ça peut paraître un peu long, cette phase de... Demandez de comprendre les process, l'entreprise, parce qu'aussi, il y a un moment où il faudra arrêter et de se dire, OK, notre produit devra ressembler à ça. Et de bien le penser pour que quand même, s'il y a des choses qui doivent se rajouter, ça puisse se rajouter après dans une deuxième version. Mais on ne peut pas non plus juste rajouter au fil de l'eau. Il faut quand même imaginer un produit fini et s'y tenir. Là,
Manu
on est en train de glisser déjà dans la phase d'après, qui est l'étape de conception. On va commencer à baliser un petit peu effectivement cette notion de version et des choses qu'on vous a expliquées la dernière fois. Juste pour terminer sur cette étape recueil de besoins, justement, tu l'as évoqué rapidement, qu'on doit distinguer justement ce qui est du fonctionnel du non fonctionnel. Est-ce que tu peux nous clarifier ça un peu ?
Lulu
Le fonctionnel, par définition, c'est vraiment ce que le système va faire. Et le non fonctionnel, c'est comment il va le faire. Et ça, on en avait parlé justement dans l'épisode précédent. Toute la phase de PRD et les user stories, ça va vraiment être dans le fonctionnel. Et le non fonctionnel arrive seulement après.
Manu
Ouais. En fait, disons, quand on va réfléchir à nos besoins, et prendre les infos et discuter avec les gens, etc., on va d'abord se concentrer sur le fonctionnel. Donc en gros, qu'est-ce que... le logiciel doit faire pour répondre à leurs besoins et le non fonctionnel ce sera l'envers du décor et la partie un peu plus technique un peu plus galère de se dire ok Ils ont besoin d'un logiciel qui leur permet de cliquer et de faire telle et telle action. Mais en fait, est-ce qu'ils en ont besoin sur leur ordinateur en ligne, sur leur tablette, sur leur téléphone ? Est-ce qu'ils peuvent se passer du réseau ou pas ? Des points comme ça qui vont déterminer après la partie technique qui va être un peu tous les à côté, sur l'architecture, sur les langages, sur l'infrastructure, enfin un certain nombre de choses. Là où le fonctionnel, c'est vraiment dans le quotidien de la personne. qu'est-ce qui doit se faire avoir à disposition pour que ça marche et que ça...
Lulu
Qu'est-ce qu'il y a avant et qu'est-ce qu'il y a après l'utilisation, mais sans passer par le comment on va faire pour transformer l'avant et l'après.
Manu
C'est ça. Et donc, tu l'as dit rapidement, l'étape d'après, ça va être la partie conception. Et là-dessus, n'hésitez pas à revenir, on vous renvoie vers notre épisode précédent et on va passer un peu rapidement sur ces points-là. Mais c'est là en fait où on va s'attaquer au fameux PRD, au User Story. Donc le PRD en gros c'est le cahier des charges fonctionnel. Donc si vous avez bien fait votre affornement et pris toutes les infos, vous allez pouvoir le traduire en une espèce de cahier des charges qui va décrire les parcours utilisateurs qui sont souhaités, qui va permettre aussi de décrire justement ce qu'on appelle les User Story. Donc de dire chaque profil dans mon application, que ce soit un administrateur, que ce soit un utilisateur, que ce soit un... super manager, etc., chaque niveau de profil doit pouvoir faire des choses différentes dans le programme et on va lister en fait chaque chose qu'il doit faire dans le programme. C'est-à-dire, il faut qu'il puisse valider un formulaire, il faut qu'il puisse rajouter une nouvelle entrée de tel élément, il faut qu'il puisse imprimer tel document, il faut qu'il puisse télécharger telle chose, il faut qu'il puisse avoir telle information à disposition, et ainsi de suite. Encore une fois, on parle un petit peu plus de ces deux points dans l'épisode précédent, on vous y renvoie. Là, l'idée, c'est que vous ayez vraiment juste la logique de se dire à chaque fois, on passe par ces points-là. Et c'est ça qui va commencer à nous permettre de déterminer les différents briques, de déterminer les différents éléments techniques dont on va avoir besoin pour aller plus loin et avant de se lancer vraiment dans le développement.
Lulu
C'est ça, c'est vraiment, on va traduire les besoins en architecture. Enfin voilà, quelles briques ? comment ces briques vont communiquer entre elles, où vont être les données. C'est là où il y a un concept de cohésion forte-couplage faible, où chaque brique va faire une seule chose, et elle va dépendre le moins possible des autres, mais après il va y avoir ce travail de les mettre ensemble pour qu'elles fonctionnent bien. En fait, la partie... Plage fort, par exemple, pour donner une image, c'est comme si tout est un peu soudé et après, une fois que c'est mis en place et qu'on veut enlever un élément ou modifier un élément, ça va forcément impacter ce qu'il y a autour. Mais le coup plage faible, ça va être plutôt on va se mettre un rôle par brique et ça sera plus simple de les faire. C'est un peu comme ça où ça fonctionne dans certaines boîtes en feature. Et après, le but, c'est de faire de l'assemblage.
Manu
Oui, je suis en train de réfléchir à justement si j'avais... parce que ça me fait toujours penser aux bases de données, aux bases de données relationnelles.
Lulu
Oui.
Manu
Mais j'essaie de retrouver un exemple qui soit facile à vous donner. Mais en fait, l'idée de ce système de briques, c'est comme dans un système d'informations, justement une base de données où vous allez ranger les informations. C'est de se dire que chaque élément, dans la mesure du possible, doit être indépendant, quitte à ce qu'il soit relié les uns les autres. mais pour que quand vous allez toucher un point, vous n'ayez pas à toucher à tout le reste.
Lulu
Surtout si cet élément est amené à bouger, ou qu'on va devoir y tirer dessus. Si on sait dès le départ qu'il ne va pas rester fixe tel quel, il faut autant que possible faire en sorte qu'on puisse le modifier après coup, sans impacter toutes les autres fonctionnalités.
Manu
Oui, et je donne un exemple un peu cassé avec l'adresse. Mais ici on peut reprendre l'adresse. En fait, par exemple, votre adresse, ce n'est pas un seul bloc. Ça va être plusieurs éléments et si vous allez justement sur n'importe quel formulaire de l'administration et que vous avez besoin de remplir des papiers ou de vous inscrire je ne sais où, à chaque fois vous allez voir que vous allez dissocier votre code postal de la ville, vous allez dissocier le numéro de votre rue, de votre avenue, le type de rue ou d'avenue. Vous allez voir ensuite l'intitulé de votre avenue. Si vous êtes sur un immeuble, vous allez voir aussi des étages. Vous avez vu qu'en fait, toutes ces informations sont à chaque fois séparées. Puisque ça va permettre de mettre à jour les différentes informations et les différentes briques qu'il y a derrière de manière indépendante sans avoir à... changer toute votre adresse à chaque fois. Désolé, je ne sais pas si l'exemple est très parlant. Enfin, visuellement aussi, vous voyez un peu le découpage. Et en fait, il faut vous dire que dans une base de données, ça va être le même principe. Et après, quand vous allez mettre en place des fonctionnalités dans un logiciel, ça va être un petit peu la même logique. C'est-à-dire qu'on va essayer d'avoir le plus de... Comment dire ? On va essayer de ne pas réinventer la roue à chaque fois.
Lulu
Ah, nid de l'huile.
Manu
Globalement, en fait, c'est ça. C'est de se dire qu'aujourd'hui, par exemple, j'arrive sur une page web où vous avez différents boutons, vous avez plusieurs, je ne sais pas, vous avez deux tableaux, mettons, vous avez plusieurs informations au même endroit. Tout ça, si c'est un seul, une seule entité, un seul bloc, un seul élément, et que vous avez besoin de changer juste la couleur de votre bouton, en fait, potentiellement, la couleur de votre bouton est par exemple le lien qui va derrière. si tout ça est un seul élément vous avez besoin de retoucher l'entièreté et donc de ça a plein d'applications techniques derrière qui rendent le truc galère alors que si le bouton il est isolé et peut-être même encore mieux d'ailleurs on va prendre le bouton mais d'une manière différente vous avez un bouton validé qui est partout dans votre application votre site internet si vous avez un bouton justement qui est indépendant et qui est mutualisé vous allez réutiliser un peu partout si vous changez la couleur à un endroit ça va la changer partout si votre bouton il est intégré dans d'autres blocs, dans d'autres éléments, et qu'il n'est pas indépendant, vous allez devoir aller sur chaque page de votre site Internet pour changer la couleur de votre bouton. Et c'est un peu tout comme ça, globalement.
Lulu
Là, c'est bien visuel, mais c'est là où on dit qu'il ne faut pas le coder en dur, et qu'il y a un peu le côté où on va mettre en place des variables qui permettent de changer tout d'un coup. Par exemple, une charte graphique qui est peut-être amenée à bouger. C'est bien de la dissocier de tout le reste et de se dire, « Bon, bah tiens, telle couleur, si je la modifie ici, ça va la modifier partout dans mon appli, dans mon site. » Parce que sinon, aller remodifier tout à la main, c'est impossible. Ça, c'est aussi quelque chose qu'il faut garder en tête et à laquelle il faut faire attention. Parce que ça peut coûter cher. Sur le coup, on se dit, « Ah ouais, mon bouton, il est bien de cette couleur-là, c'est bien, la police, elle est bien. » Et arrivé à la fin, on a plein, plein de boutons et on se dit, « Ah, mais c'est vrai qu'un tout petit peu plus gros, ça serait pratique. » Oui, s'il faut aller le faire 20 fois ou 30 fois sur chaque bout d'eau.
Manu
Oui, par exemple, pour reprendre un exemple que nous, on a eu sur notre portail à nous en interne, c'est qu'on a plusieurs endroits dans notre portail qui nous permettent de rédiger du texte. Puisqu'il y a un endroit où on va préparer la trame de l'épisode, on va écrire dedans. Il y a des endroits où on va rédiger le texte qui va servir à la diffusion de ce podcast et qui sera présent sur un groupe. qu'on va renvoyer sur Ausha et qui arrivera dans votre Spotify, dans votre YouTube, etc. On a un autre endroit où on va pouvoir préparer le texte, on va le mettre sur LinkedIn, et ainsi de suite. On a plein d'endroits comme ça. Et là, l'idée, plutôt que d'avoir là aussi plein de briques du coup indépendantes, mais chacun sur leur interface, on va dire ça comme ça, on a pensé la mutualisation, et donc j'ai un éditeur qui va être réutilisé un petit peu partout et qui va partager des fonctionnalités. Et dans des cas particuliers, lui soit il va être il y aura une déclinaison différente de lui, soit ce sera complètement un autre éditeur, si jamais vraiment on est sur un cas très spécifique et très particulier. Mais on va toujours penser, voilà, tout ce qu'on fait dans une application, dans les interfaces, on va le penser en système de briques, avec qu'est-ce qui est commun, qu'est-ce qui est réutilisable, qu'est-ce qui vaut mieux dès maintenant, penser pour être réutilisé un petit peu partout dans l'application, plutôt que de faire que des petits morceaux et de devoir repasser partout à chaque fois qu'il y a une modif, et du coup de faire des bêtises.
Lulu
Parce que là, c'est vrai qu'on est sur du visuel, mais si on a une application et qu'on développe, par exemple, une fonction qui va faire quelque chose, on ne va pas avoir plein de fois cette fonction différente. Parce que même après, en termes de performance, ce n'est pas ce qu'il y a de plus efficient non plus. Et là, ça peut se ressentir au-delà juste du visuel.
Manu
Oui, c'est que concrètement, si vous avez 10 pages dans votre outil de tous les jours et que vous avez 10 fois les mêmes choses, en fait, ça va ramer vachement plus que si vous l'aviez une fois. et que c'était la même chose qui était réutilisée un petit peu partout.
Lulu
Et c'est plus simple de le penser dès le départ que de se dire après coup, comment est-ce que j'optimise mon application ?
Manu
Et là où le raccourci qui peut être fait souvent, enfin souvent, pas souvent, mais en tout cas selon les philosophies, selon les cas, ça peut être un mauvais réflexe, on va dire, de se dire bon, j'ai envie de sortir vite une nouvelle chose, une nouvelle fonctionnalité, de vouloir aller au plus court. Et souvent, le chemin le plus court, c'est d'aller pas penser en termes de mutier. de mutualisation et de réutilisation. et de faire juste la chose la plus simple possible. Mais du coup, ça a des implications derrière, parce qu'une fois qu'on va commencer à empiler des choses là-dessus, c'est d'autant plus dur. On en revient à l'exemple de tout à l'heure avec le coup de la maison. C'est que typiquement, si vous faites une canalisation un petit peu à l'arrache, et que le reste suit, vous allez commencer à mettre votre sol par-dessus. du coup vos meubles, votre tapis, vos machins et qu'après vous vous rendez compte qu'en fait il faut refaire toutes les canalisations parce que vous en avez pensé qu'une et qu'il en fallait trois, vous allez devoir littéralement tout virer et tout reprendre pour ensuite aller faire les différents chemins derrière. Alors ça n'impliquera pas de tout recasser mais en tout cas de tout bouger.
Lulu
Ou de faire du bricolage et de ne pas faire aussi bien que si ça avait été pensé dès le départ. Et aussi optimiser, voilà. Ça demande de prendre en compte l'existant, de ne pas tout enlever. Alors dans tous les cas, Enfin voilà. On ne peut pas tout prévoir, mais il faut quand même se poser. Là, juste pour passer aussi un peu à la partie d'après, parce qu'au final, on parle, on parle. Là, je pense que tu seras peut-être plus apte à en parler, tout ce qui est développement et versionnage. Parce que c'est vrai que maintenant, avec le développement assisté par IA, le vibe coding, on parle beaucoup de Git et GitHub sans forcément savoir ce que ça implique. comment ça fonctionne et pourquoi c'est utile aussi.
Manu
Oui. Alors, on va reprendre dans l'ordre. Donc, jusque-là, d'accord, on a été parler avec des gens, on a trouvé un problème, on a identifié du coup qu'est-ce qui pourrait y répondre. À partir de là, on s'est posé pour réfléchir à de quoi on a besoin dans notre application pour répondre à ce problème et on a pensé un petit peu les interfaces et tout ça. Donc normalement arrivé à ce moment là, on a un petit peu tout sur papier ou sur numérique, on a une maquette, on a plein de cahiers de décharge, on a plein d'informations. On voit vraiment ce qu'on veut faire et on voit vraiment les interfaces, donc grosso modo ce qu'on veut vous mettre dans les mains pour que vous puissiez vous en servir. Maintenant, il va falloir s'attaquer au développement. Mais le développement, je vais prendre le cas d'une équipe avec plusieurs personnes pour que ce soit un peu plus prudent. si chacun... doit bosser. En mettant que vous avez trois développeurs et développeuses, ces trois personnes vont devoir travailler. Elles ne vont pas pouvoir bosser sur le même sujet en même temps. Puisque techniquement, en fait, ça ne va pas le faire.
Lulu
L'intercom de l'analogie d'un document partagé en ligne où on veut travailler tous sur le même paragraphe en écrivant, effaçant, c'est juste impossible.
Manu
Oui, voilà, exactement. Ça ne marchera pas. Il faut se séparer, se dire dans ce document, On a trois parties, chacun va bosser sur une partie. Et voilà, ça va être le postulat de départ. Mais pour que ça puisse fonctionner, et que chacun puisse bosser de son côté sur sa partie, et qu'on puisse après tout réunifier en un seul document, il faut mettre en place un protocole, et on va mettre en place ce qu'on appelle un protocole qui permet de faire du versionnage, et un des plus utilisés aujourd'hui, c'est Git. Alors je ne vais pas rentrer dans l'historique maintenant, déjà parce que je ne l'ai plus trop en tête. mais en gros ce protocole va être très utilisé notamment par GitHub et GitLab qui sont deux des plus gros acteurs dont vous avez pu entendre parler, ou en tout cas voir le nom. Mais il y en a d'autres, il y a d'autres systèmes de versionning, certains qui s'appuient aussi sur Git mais qui ont une façon de le gérer différemment, d'autres qui n'utilisent pas Git et qui font encore autre chose. Mais dans tous les cas, le principe de Git c'est de se dire on a notre document final qu'on va appeler le main. qui va être vraiment notre... C'est la page commune, c'est la page que la personne va voir à la fin, que l'utilisateur va voir à la fin. Et c'est là que tout doit arriver. Mais on ne peut pas mettre à disposition et en lecture le brouillon. Parce que pendant que les gens bossent sur chaque partie, ce ne sont que des brouillons de chaque partie. Donc sur cette page, on va attendre que chacun ait terminé. Et pour faire ça, le protocole va permettre à chacun d'aller travailler sur ce qu'on appelle les branches. des branches. Vous n'êtes pas obligé d'utiliser des branches, mais quand vous êtes une équipe, normalement, c'est ce qui se fait. C'est que chacun travaille sur une branche. Et en fait, sur chaque branche, donc globalement, dites-vous qu'en fait, le document principal, pour l'instant, il a juste une introduction. Vous avez fait trois copies de ce document. Chaque personne travaille sur une partie différente de ce document. Et au fur et à mesure que chaque personne va avoir une partie ou un paragraphe qui est terminé, on va dire un paragraphe, c'est comme s'il appuyait sur enregistrer. Et à partir de là, ça va faire ce qu'on appelle un commit. Donc en gros, il va valider cette section-là, enfin voilà, ce paragraphe, il va le valider, il va dire OK. ça c'est bon, je considère qu'il est prêt, et même si j'ai besoin d'aller rajouter des choses plus tard au travail, mais en tout cas cette partie elle est enregistrée, elle est disponible, elle est visible sur ma branche, et du coup même les collègues s'ils viennent regarder ma partie, ils ne verront pas le deuxième paragraphe sur lequel je suis encore en train de bosser, et par contre le premier ils vont le voir. Et en fait chacun fait ça de son côté, et à partir de là, une fois que chacun fait tous ses commits, donc tous ses paragraphes et que les trois parties sont à peu près prêtes, Et voilà, ça peut être à des rythmes différents en fonction des personnes. Et puis de la charge aussi, parce que ça fait partie aussi des logiques de développement. C'est de se dire qu'en fait, tout le monde n'a pas forcément la charge, le même effort de travail sur une partie. Il y en a des plus courtes, il y en a des plus longues. Et chacun peut avoir ses spécialités aussi. Et voilà, qui vont avoir du coup des choses qui peuvent bloquer d'autres gens. Par exemple, la partie 3, peut-être que la personne va pouvoir faire les deux premiers paragraphes, mais pour le troisième, elle ne pourra pas le rédiger tant qu'elle n'aura pas les parties 1 et 2 qui sont terminées. Il peut y avoir comme ça des systèmes de dépendance. Dans l'idée, on va répartir en parallèle le travail de chacun. Une fois que les trois parties sont prêtes, ils vont faire ce qu'on appelle des pull requests. Le mot fait très peur, mais le concept est très simple. C'est de se dire, j'ai fini ma partie, je l'envoie à relire et à valider par les copains. Et en fait, cette partie-là n'arrivera pas dans le document principal tant que... les collègues devs n'auront pas relu. Ils vont venir, ils vont regarder. OK, en fait, tu as écrit ce paragraphe. OK, ça, c'est bien. Ah, là, il y a un petit souci. Du coup, on va le pointer en disant, en fait, cette partie-là, il faut un petit peu la remanier parce qu'elle ne me semble pas bonne. Il y a un truc qui ne va pas. Donc là, la personne qui a rédigé justement la partie, elle va venir, elle va faire la petite modif. Hop, elle va resoumettre à validation. Et donc là, on va du coup... Les collègues vont dire, ok, très bien, cette pull request, cette PR, si jamais on vous entendait parler de PR, c'est ça en fait. Là, je parle de paragraphe, mais dites-vous que c'est du code. Depuis tout à l'heure, je vulgarise comme ça avec l'exemple du document, mais à la place du texte, dites-vous que c'est du code. Et donc, une fois que la PR est prête, elle va être validée et elle va partir, justement, elle va fusionner avec la page principale, donc avec le main. Et ensuite, du coup, on va continuer comme ça. Chaque fois, les pull requests vont avoir plus ou moins de... Soit elles vont être validées directement, soit elles vont demander plusieurs allers-retours, plusieurs correctifs, mais ça va être cette logique-là. Et des fois, il peut y avoir aussi deux PR qui vont être en conflit. C'est-à-dire que, justement, chacun bossait sur une partie différente, partie 2 et partie 3, mais en fait, il y avait un paragraphe qui était commun entre les deux et que les deux personnes n'ont pas la même version du paragraphe. Il y a une phrase ou deux qui diffèrent. Et bien là, au moment de fusionner, il va falloir choisir avant de fusionner quelle version du paragraphe on garde, et laquelle en fait est la plus récente, la plus à jour, et la plus logique par rapport à l'ensemble du document. Puisque en même temps, comme je disais, on travaille en parallèle, donc il peut y avoir d'autres gens qui ont avancé davantage sur d'autres bouts, et qu'on n'avait pas forcément conscience à ce moment-là, et donc voilà, on fait une relecture. D'où l'importance de ces phases qu'on appelle des phases de review, vraiment, du PR, donc de relire. le document et la partie de document. Une fois que tout est prêt, à chaque fois, on va fusionner, on envoie dans le document principal et les pages s'ajoutent. Évidemment, vous l'aurez compris, cette page principale, ce document principal, c'est votre code de l'application et ça se traduit pour vous en tant qu'utilisateur en une interface avec des choses à cliquer, avec des pages, avec plein de choses comme ça. Est-ce que sur cette partie-là, Lulu, tu veux que je clarifie d'autres points ? Je ne sais pas si tu avais d'autres points. Non,
Lulu
ça me semble... Ça me semble bien et ça montre d'autant plus l'intérêt d'utiliser ces techniques-là, même si on développe tout seul avec plusieurs agents. Parce que là, d'autant plus, on se rend compte que le code avec IA va produire du code où tout est plus ou moins dépendant. Ce n'est plus forcément séparé par section claire, surtout si on n'a pas bien défini en amont et qu'on envoie notre agent. coder sur une fonctionnalité mais on ne l'a pas forcément bien découpé donc ça va toucher à plusieurs endroits du code. Donc imaginez, vous avez plusieurs agents qui travaillent en même temps sur un projet qui est en local, ils vont peut-être essayer de modifier des choses au même moment, au même endroit, et là après ça peut tout casser, ou induire des doublons, enfin voilà. C'est pour ça que c'est important, même si on développe tout seul, d'utiliser d'utiliser et... Git, bon après même si c'est en local, on peut utiliser Git quand même, mais après GitHub permet aussi de... Enfin, c'est vrai qu'il y avait la distinction, moi avant je ne connaissais pas forcément la distinction Git-GitHub, pour moi c'était la même chose et Git c'était en mode... Juste le raccourci,
Manu
l'abréviation. Je vais juste effectivement clarifier un peu ce point-là. C'est que le protocole Git, à la base, il permet de travailler sur son propre ordinateur avec ce système de version, de se dire à chaque fois, je fais une nouvelle version. Je vous ai parlé là des fusions et tout, mais je n'ai même pas revenu sur le terme de version. Mais du coup, le fait d'avoir des commits et après votre pull request et ensuite de venir justement fusionner tout ça, ça vous permet d'avoir une nouvelle version. Vous n'êtes pas obligé de faire des pull requests pour quand même... versionnés petit à petit au fur et à mesure des changements. J'ai pris l'exemple du contexte entreprise où on est à plusieurs et d'où les fameuses PR. Et effectivement, ce que vous allez avoir comme du GitHub ou du GitLab permet en fait d'avoir ce code et ces versions de code et tous les changements qui partent sur un serveur cloud. Donc chez GitHub, c'est chez du Microsoft aujourd'hui. Et GitLab, je pense que c'est juste GitLab d'ailleurs, je crois qu'ils n'ont pas d'instance au-dessus. Mais l'avantage de ça, c'est que du coup, le code va être centralisé sur un espace commun sur Internet. Et donc, n'importe quel développeur ou développeuse va pouvoir bosser sur son ordi en local, faire toute sa partie jusqu'au bout. Et une fois que sa partie est prête, elle va pouvoir faire le point avec ce qui est disponible en ligne. Et elle va l'envoyer en ligne et justement soumettre à validation pour lecture, etc. Et c'est aussi des fois d'ailleurs comme ça qu'on se rend compte qu'il y a des conflits. Autre personne, en bossant sur son ordi, au moment où elle a envoyé le code, elle est plus avancée que moi sur un truc qui était commun, et ainsi de suite. Et sur la manière de bosser en solo avec des agents, il y a plein de manières de le faire, avec plus ou moins de pull requests, avec plus ou moins d'enregistrements, etc. Mais ce qu'il faut garder en tête, c'est que Git, du coup, enfin Git ou un autre protocole de versionning, est très important, parce que ça vous permet en fait... de sauvegarder petit à petit votre progression et ce qui a été fait côté code, ça donne aussi des points de restauration. Donc en fait, si vous avez un pépin et que vous vous rendez compte que vous avez fait quelque chose qui ne marche pas et qui casse votre application, vous pouvez revenir en arrière sur une version antérieure. Et voilà, ce qui est fondamental, que ce soit tout seul ou à plusieurs. Et l'autre intérêt aussi de bosser comme ça, justement avec des branches, avec des versions et tout, c'est de se dire qu'en fait, à tout moment, Quelqu'un peut arriver sur votre repository, donc en gros sur votre dossier avec tout votre code, et qui peut reprendre le travail. De se dire, demain, s'il y a un dev qui arrive, qui prend mon code, il va pouvoir savoir où j'en suis, il va avoir l'historique de tout ce que j'ai développé, s'il y a une fonctionnalité qui fonctionne bien ou pas bien, il va pouvoir remonter, du coup, voir non seulement le détail du code, mais aussi l'historique qui est associé, et être à même de comprendre d'où vient le problème. ou qu'est-ce qu'il pourrait faire pour l'améliorer ou comment on va rajouter une nouvelle fonctionnalité, etc.
Lulu
D'où l'intérêt de bien documenter, de bien commenter aussi son code. Alors, c'est sûr que quand on est avec de l'IA, on ne va pas forcément lire le code, mais je pense que même pour suivre un projet, ça peut être intéressant de juste voir comment c'est fait et que ce soit pour qu'un humain ou une IA reprenne derrière des noms de fonctions clairs qui disent exactement ce qu'elles font, ou bien découpés. aussi une fonction à tout faire et de bien commenter, de bien documenter. Parce que que ce soit une IA, vous dans six mois ou quelqu'un d'autre, vous serez content de retrouver les commentaires et il faut penser à ceux qui viennent après. Petite référence à Claire Obscur. J'ai réussi.
Manu
Alors, du coup, est-ce qu'on se lance sur la partie d'après ou est-ce qu'on s'en tient là pour aujourd'hui, Lulu ?
Lulu
Je me dis qu'on peut quand même attaquer les tests parce que tu vas peut-être en parler pas mal la semaine prochaine et ça serait bien de dire au moins les différents... Parce que c'est pareil, notre application, à la fin, on ne va pas se dire « Ah bah tiens, je vais la tester à la fin » . C'est vraiment quelque chose qu'il y a à mettre en place à chaque étape de développement aussi et de se demander aussi, même avant de commencer à développer, de définir ses tests. En partie, mais je pense que là, tu en parleras un petit peu mieux parce qu'il y a différents types de tests. On entend parler, tu avais parlé aussi de recettes la semaine dernière. Et après, il y a les tests de régression, tests unitaires. Ça aussi, c'est du vocabulaire qui peut paraître un peu barbare quand on n'est pas dedans.
Manu
Oui, effectivement. Ok, alors, parce qu'on a déjà fait un petit peu long sur les trois premières parties, donc là, on va essayer d'aller un peu plus vite sur les trois suivantes. mais que vous ayez le panel complet justement du cycle de développement dès aujourd'hui n'hésitez à nous faire basculer sur deux épisodes pour vous n'ayez pas à vous en mettre trop dans la tête d'un coup. Mais en même temps, je pense que ce serait un peu frustrant de s'arrêter aussi à la moitié. Donc, je rejoins Guillaume. Au pire,
Lulu
vous écouterez en deux fois.
Manu
Oui, c'est ça. Ce sera pareil. Et alors, les tests. Les tests, les tests. Effectivement, il va y avoir plusieurs choses. On ne pourrait pas en parler longuement parce que ce que vous avez sous le nom d'assurance qualité ou de QA dans les entreprises, en tout cas chez les éditeurs de logiciels, c'est les services des... volontaire ou désigné volontaire pour aller casser les produits et les logiciels et trouver toutes les failles et les remonter aux développeurs qui vont râler parce qu'ils ont des nouvelles failles et des nouveaux bugs à corriger mais qui est fondamental pour éviter que ces bugs arrivent dans les mains des gens à la fin. Donc la première chose ça va être effectivement de penser les tests dès le départ donc ça on en avait déjà aussi parlé dans l'épisode précédent c'est de se dire quand on écrit une user story et qu'on dit tel profil doit pouvoir faire telle chose dans l'application on va y associer des critères d'acceptation, donc de dire en fait, pour valider que cette fonction-là, donc quand il clique dans ce bouton, ça marche, en fait, c'est les critères qui vont dire qu'est-ce qui fait que ça marche ou pas. Et associé à ça, en fait, on va avoir justement un carnet de tests ou un cahier de tests ou un carnet de recettes, enfin bon, plusieurs appellations. Mais en fait, en face de chacune de ces user stories, on va mettre des tests pour se dire, pour que tout... Ce bouton, il doit, par exemple, permettre d'ajouter une ligne dans mon tableau. Mais du coup, il faut que je teste tous les cas possibles et impossibles, c'est où ça devient rigolo, les fameux cas limites, de se dire en utilisation normale, la personne va remplir ces deux champs, cliquer sur le bouton, ça rajoute une ligne. Et en fait, si dans ces deux champs, j'ai un champ nom, j'ai un champ prénom, à la place, si elle met des chiffres, qu'est-ce qu'il se passe ? Si elle met des caractères spéciaux, qu'est-ce qu'il se passe ? Si elle ne met rien, qu'est-ce qu'il se passe ? Si elle met un script,
Lulu
qu'est-ce qui se passe ?
Manu
Si elle met un script, qu'est-ce qui se passe ? Ou si elle met... Alors ça, c'est un des tests qui est assez rigolo, d'ailleurs, quand on les voit passer. Si on met un texte sans fin dedans avec 2000 caractères, qu'est-ce qui se passe ? Et voilà. Et ensuite, à partir de là, on en déduit les tests à faire et la perce. Pas faire tout à fait dans ce temps-là. À ce moment-là, vous avez déjà un scénario de test qui est associé à chaque... un ou plusieurs scénarios de test qui sont associés à chaque fonctionnalité, globalement.
Lulu
C'est vraiment plus large et ça ne va pas tester juste un petit bout. On est vraiment dans le... On teste une fonctionnalité, une user story. On va tester une fonction dans le code. Là, on est vraiment sur presque le plus haut niveau de test, je pense.
Manu
Oui, c'est ça. C'est-à-dire qu'en fait, on va avoir plusieurs niveaux de test. Il va y avoir les tests... unitaire donc ça ça va être vraiment purement au niveau du code de se dire ben voilà le développeuse a créé a développé ce bouton qui permet de valider d'ajouter la nouvelle ligne avec les noms prénoms elle va mettre en place un test unitaire au niveau du code pour dire ben en fait quand je clique ça fait exactement ça insère donc un ajout du nom prénom dans la ligne de ces deux champs voilà typiquement test unitaire il va être là
Lulu
C'est une brique, on teste vraiment juste une petite brique, indépendamment du reste.
Manu
C'est ça. On va avoir des tests d'intégration. Selon les cas, ils viennent à des moments un peu différents, mais qui vont être là un petit peu pour l'environnement. Je vais en reparler juste après de cette notion d'environnement. Et donc, ils vont être un peu plus sur la partie vraiment technique, globalement, mais technique, pas du code, mais tout ce qu'il y a autour. le fait que le programme est disponible, où est-ce qu'il est disponible, de quelle manière il est disponible, un petit peu plus ces choses-là. Et on va avoir les tests dits end-to-end, qui sont en fait les tests type utilisateur, c'est-à-dire vraiment les tests de ce qui se passe quand on navigue sa souris dans le logiciel, ou sur le téléphone par exemple, et qu'on clique directement sur les boutons, etc. On reproduit le comportement d'une... personnes utilisant vraiment l'application. Et ces trois tests-là, déjà, on va pouvoir les... Comment dire ? On va pouvoir les automatiser, déjà. Test unitaire, intégration, etc. Les tests end-to-end, en fait, quand on les automatise, c'est qu'on va littéralement avoir un programme qui reproduit des clics à l'écran et qui reproduit des actions utilisateurs. Donc ça, c'est assez marrant à voir quand vous le faites. Et voilà, d'ailleurs, si vous développez avec de l'IA et que vous faites du vibe-coding, ben... demandez enfin j'espère que vous faites des tests end to end et quand il s'est le cas justement amusez vous à regarder les fenêtres de tests pendant qu'il les fait pour voir justement ce ces interactions en temps réel et Il y a des programmes qui sont dédiés, etc. pour faire ça. Mais les familles de tests, en gros, ça va être là-dessus. Après, on va avoir des tests de non-régression. Donc les tests de non-régression, en fait, entre guillemets, il peut y avoir un peu tout ça dans le lot, mais le but, c'est de se dire, en gros, quel est notre panel de tests dans les différentes familles qui valident et vérifient que notre programme n'est pas cassé et qu'on a... pas cassé un bout du logiciel en ajoutant une nouvelle fonctionnalité, même si, a priori, la nouvelle fonctionnalité n'avait rien à voir. Parce que ça, c'est un des cas, justement, des effets de bord, c'est de se dire en fait, je sais pas, je rajoute une nouvelle page dans mon programme, cette nouvelle page elle permet de faire des... de rajouter des tableaux alors qu'avant j'en avais pas, mais en fait, quand elle rajoute des tableaux, elle utilise un bouton qui était utilisé à un autre endroit et qu'en fait, ce bouton, du coup, on l'a retouché sans se rendre compte qu'il était utilisé à un autre endroit et ça va casser à ce moment-là. Ça marchera bien sur la page avec le tableau, mais ça marchera plus sur l'autre page qui utilisait le même bouton. Voilà, les tests de non-régression, en fait, ils sont là pour empêcher ça, enfin, pour empêcher ça, pour se rendre compte de ça. Parce que là,
Lulu
en plus, on parle de boutons où c'est visible, mais ça peut être des choses qui s'accumulent sans qu'on s'en rende compte, jusqu'à un point où c'est pour ça que c'est vraiment important de le penser et de garder ça en tête et de se dire que c'est pas parce que je modifie une partie là, d'autant plus si c'est en développement assisté par IA ou... On peut avoir un peu de code spaghetti, où il y a tout qui s'entremêle. Se dire, non, mais ça va, visuellement, je ne modifie que quelque chose qui est là, mais derrière, au final, ça va aller toucher d'autres choses et on ne s'en rendra pas compte avant de peut-être modifier autre chose ailleurs aussi. Donc, ça peut être vraiment exponentiel.
Manu
Oui, et là, c'est vrai que je parle beaucoup de boutons et de choses. Pour que vous arriviez à avoir quelque chose en tête, parce que déjà qu'on est quand même très abstrait sur plein de sujets, concepts, parce que si vous n'avez jamais fait de développement, C'est normal, ça fait beaucoup de nouveautés, de nouvelles idées, de nouvelles choses à intégrer. Mais dans la réalité des faits, effectivement, la majorité des cas et des bugs viennent de choses qu'on ne voit pas de prime abord. Même s'il y a aussi des petits tests, il peut y avoir des petits bugs d'interface, il peut y avoir des caractères. Il y a des choses qui sont visuelles, mais les soucis et les bugs les plus embêtants, comme disait Lulu, on ne les voit pas.
Lulu
C'est ça, et aussi de se rendre compte à quel moment on a cassé. parce que si on se rend compte que... rapidement, ça peut être facile de corriger tout de suite, de revenir à une ancienne version, de refaire autrement. Mais si on s'en rend compte plusieurs jours, plusieurs semaines après, et ça c'est vrai qu'IA accélère énormément le développement, les pull requests, et au final c'est le lenteau nord, le goulot d'étranglement, il est au niveau de la revue de code maintenant, et avec tout ça qui arrive très très vite, s'il y a quelque chose qui... passe à la trappe, mais on va rajouter d'autres choses, d'autres fonctionnalités, ce qui fait qu'on ne pourra pas juste se dire « je reviens en arrière au moment où ça a pété » , parce qu'il y a d'autres choses qui sont rajoutées en même temps et c'est là qu'on se retrouve à faire des choses pas très propres en général.
Manu
Oui, c'est là qu'on se retrouve avec de la dette technique, notamment. En fait, la dette technique, sur les cas où vous pouvez, les plus criards, vous pouvez en avoir, ça va être justement quand, au début, vous aviez une fonctionnalité à faire. vous voulez rajouter une nouvelle chose et en fait vous voulez la rajouter le plus vite possible sans vous prendre la tête à vous dire, en fait, est-ce que pour la faire bien, ça prendrait vachement de temps, c'est vachement complexe et il faut anticiper plein de choses. Moi, je veux juste que les utilisateurs et les utilisatrices l'aient très vite dans les mains. Je la fais de la manière la plus printée et la plus express. Sauf que la manière dont elle est conçue, effectivement, ça va pour deux semaines et un cas défini. Mais en fait, dès qu'on va vouloir... rajouter des choses sur cette fonctionnalité, on va se rendre compte que non, ce n'est pas possible parce que ce n'est pas qu'elle est mal conçue, c'est qu'elle n'est pas pensée pour évoluer.
Lulu
Ça ne prend pas forcément beaucoup de temps de faire des tests à chaque étape. C'est aussi à penser et que ça peut vraiment sauver son application après.
Manu
Alors, oui, justement, c'est là où je voulais revenir. Là, déjà, il y a de la technique juste de... de ne pas avoir anticipé assez ou d'avoir voulu aller trop vite et de manière qui ne peut pas évoluer derrière. Et par-dessus ça, on va rajouter les problèmes et les bugs liés au manque de tests et au manque de tests de qualité qui ne vont pas permettre de se rendre compte que cette fonctionnalité qu'on a développée très vite, elle a des problèmes qui sont visibles dès maintenant et qu'on va retarder. Et parmi ça, il peut y avoir par exemple des soucis de performance. Typiquement, il peut y avoir des... Vous rajoutez une nouvelle page qui va vous permettre de rajouter, en plus de votre nom, prénom, vous allez pouvoir rajouter votre adresse. Mais en fait, toute cette partie-là, elle est très mal faite. elle a été faite à l'arrache, elle n'est pas évolutive, et surtout elle consomme énormément de ressources. Et en fait, sur le moment, ça passe, parce que vous ne rajoutez que ça, mais vous allez vouloir rajouter une suite au formulaire pour aller prendre des informations complémentaires, et en fait, chaque fois que vous rajoutez des blocs sur votre formulaire, vous vous rendez compte que ça devient très très lent, et que toute la page ram. Et en fait, le problème va venir d'un des tout premiers composants, votre adresse. qui, rien que le fait qu'elle tourne sur la page, va consommer vachement de ressources de votre navigateur Chrome et va faire des ralentissements. Mais dès que vous allez faire d'autres choses supplémentaires, rajouter des composants, ça va rendre tout ça exponentiel. Chaque composant va rajouter le même ralentissement et à la fin, vous allez retrouver, quand vous cliquez, qu'il va devoir attendre plusieurs secondes pour qu'il se passe quelque chose, par exemple. Ça, c'est un cas de technique classique de l'IA de la performance qui peut être décelé notamment à travers des tests automatisés. Parce qu'en fait, dans les tests automatisés ou pas automatisés d'ailleurs, puisque c'est là, on va se rendre compte qu'il y a un problème. Si quand on clique sur le bouton, ce n'est pas immédiat et instantané et que ça prend 10 secondes, c'est qu'il y a quelque chose qui ne va pas quelque part. Et donc dans la QA, dans les services d'assurance qualité, comme ça, ils vont être en mesure de faire les deux, la partie test automatisé, mais aussi la partie test vraiment humaine, de se dire, OK, la machine, j'ai pu mettre en place un certain nombre de trucs pour que ça tourne tout seul. Parce qu'en fait, on invite des centaines de tests. Et donc, à chaque fonctionnalité, on ne peut pas faire des centaines de tests à la main. Mais à côté de ça, il y a besoin d'avoir ce regard humain pour se dire, attention, parce qu'en fait, ce truc-là, je n'ai pas pensé qu'on pouvait le prendre de telle ou de telle manière. Ou alors, le test que j'ai mis en place, il est bien, mais en fait, il ne dira pas si, justement, quand on va rajouter la prochaine fonctionnalité qui est prévue avec l'équipe, ça risque de poser souci. Et là, du coup, la personne... les personnes justement dans le service qualité apportent énormément de valeur côté produit et information. Au même titre que les utilisateurs finaux justement qui vont se servir de votre produit, mais à la qualité, en fait, ils vont avoir un regard tellement complet sur votre application qu'ils sont en mesure de vous montrer des choses, d'essoler des choses que vous ne pourriez pas faire différemment, que vous n'auriez pas pu voir différemment. On va dire ça comme ça. Et juste pour terminer justement sur ce sujet des tests, pour faire le lien avec notre...
Lulu
Là, tu as parlé des tests de non-régression, mais il y a aussi les tests de régression encore.
Manu
En fait, techniquement, c'est les tests de non-régression qui te font valider l'absence de régression. Ah, oui,
Lulu
d'accord. Parce que moi, j'avais tendance à entendre tests de régression, mais c'est tests de non-régression.
Manu
Du coup, je dis peut-être une bêtise sur le vrai terme officiel, mais j'ai toujours dit tests de non-régression, c'est un balut le principe étant que justement t'es toute ta suite de tests automatisés pour t'assurer comme on disait avant que quand t'as rajouté quelque chose, en tout cas t'as un palier de sécurité qui a tourné tout seul et voilà qui sont parmi les différents tests qu'on a déjà évoqué avant mais qui vont être aussi une sélection et il y a aussi le fameux smoke test,
Lulu
je ne sais pas si tu veux nous en parler de celui-là ça je l'ai découvert en préparant l'épisode c'est un à... Test, alors, il vient, c'est test de fumée, pour traduire littéralement, qui vient de l'électronique. En gros, c'est on va allumer et s'il y a de la fumée qui sort, on arrête et on considère que ce n'est pas bon. Voilà, donc en logiciel, on va lancer, on va faire des vérifications qui sont vitales. Et si ça ne passe pas, juste on ne va pas continuer à faire d'autres tests et investir du temps sur cette... partie-là du logiciel ou sur cette version du logiciel, parce que ça serait une perte de temps et de ressources.
Manu
Oui. Je suis en train de penser à mes usages, mais effectivement, c'est un test qui va à l'essentiel.
Lulu
Si ça, ça ne passe pas, on ne va pas aller vérifier si le bouton a la bonne couleur. Il y a d'autres choses à vérifier en amont. Et c'est vrai que quand tu parlais du formulaire aussi, On se dit, mais comment est-ce qu'on peut tester tout ? Parce qu'au final, c'est presque infini ce qui peut se passer. Et justement, on va essayer de choisir à chaque fois des valeurs ou des tests qui vont être représentatifs d'un intervalle ou qui vont être représentatifs de plusieurs tests qui vont permettre, par exemple, si on peut mettre des numéros, on va se dire, bon, on va tester, par exemple, je ne sais pas, 0, 1.
Manu
après on va tenter sans tester après aussi à chaque borne où on peut mettre, c'est souvent là où ça peut bugger si on met un nombre négatif si on met un chiffre à virgule et ça va pas être pertinent de tester tous les chiffres tous les nombres et juste prendre un test ou une valeur qui va représenter une famille de valeurs ouais et en fait il faut Ouais.
Lulu
à garder en tête, c'est qu'on ne peut pas tout tester. C'est juste pas possible. Et aucun logiciel n'a pas de bug. L'idée, c'est de ne pas avoir de bug visible, entre guillemets, et les traiter au fil de l'eau, justement de ne pas attendre qu'ils s'accumulent et qu'ils s'agglutinent, et surtout de traiter tous les problèmes majeurs le plus rapidement possible, mais sans pour autant délaisser les petits bugs mineurs, parce qu'en fait, il y a des soucis. Il peut y avoir des... petits pépins et des petits bugs moins importants mais qui sont pénibles dans l'utilisation quotidienne et qui sont aussi nécessaires de corriger petit à petit. Mais typiquement, il peut y avoir des cas où vous avez des bugs qui sont connus, qui ne sont pas traités volontairement parce qu'on sait que telle page ou tel composant, on va le faire évoluer. C'est déjà prévu qu'il évolue dans deux semaines, dans un mois. Et l'effort que ça prendrait de corriger le bug est beaucoup trop important. au vu du fait que de toute façon, cette partie-là va être refaite différemment et on ne va pas faire le boulot deux fois. Donc c'est ce qui fait aussi des fois que vous avez des bugs dans certains logiciels que vous allez voir, vous savez qu'ils sont là. Donc des fois, ils ne sont pas traités de suite parce qu'en fait, il n'y a plus prioritaire avant, il y a plus important et plus urgent et plus critique dans l'application. Et d'autres fois, mais en fait, ils sont connus, acceptés, tolérés parce que... la fonctionnalité ou le composant va être amené à changer. Et dans ces cas-là, soit il faut prendre son mal en patience, soit ne pas hésiter aussi à solliciter les services support, les équipes support qui ont généralement... C'est tout à l'aimant. Oui. Généralement, des astuces et des contournements à vous donner qui ne sont pas forcément idéaux, mais qui peuvent vous permettre de vous débloquer pour quand même arriver à vos fins sans avoir à attendre justement que la fonctionnalité soit terminée et que la nouvelle version soit disponible.
Manu
C'est vrai que c'est compliqué de trouver un peu cet équilibre entre la partie maintenance et régler des problèmes qui remontent, et la partie innovation où on veut rajouter des nouvelles fonctionnalités, parce que c'est sûr qu'il y a ce côté-là où le produit doit quand même vivre, l'application doit vivre, et on ne peut pas juste tout régler parce qu'il y a d'autres choses qui vont arriver, comme tu disais, au fil de l'eau. trouver un peu ce sweet spot entre on fait quand même évoluer l'appli, mais en même temps il ne faut pas qu'on casse tout et qu'on construit sur quelque chose qui est bancable. C'est pour ça qu'il y a certains moments aussi, on verra, où c'est mieux de recommencer. Ce n'est pas agréable, ça peut être compliqué, ça peut coûter, mais ça peut aussi coûter d'essayer de continuer à essayer de maintenir et de... pu avoir d'innovation et de se faire potentiellement dépasser par quelqu'un qui lance son nouveau logiciel.
Lulu
Oui, après, voilà, ça serait complètement vrai, mais ça va dépendre aussi de l'envergure de l'application et de l'objectif. Si vous faites du vape coding et que vous développez une application toute seule ou toute seule sur votre ordi, globalement, votre appli, une fois qu'elle est terminée et qu'elle répond à vos besoins, vous n'aurez peut-être jamais besoin de la faire évoluer pendant des années, et puis au bout d'un moment, juste... passer sur un autre produit ou faire une nouvelle version, enfin, peu importe. Et la même chose sur certains modules et certaines applis. Des fois, vous allez remplacer un logiciel entier par un nouveau qui est pensé différemment et qui correspond davantage à vos besoins. Ou au contraire, du coup, effectivement, des logiciels qui vont durer très longtemps vont de temps en temps changer des bouts de moteur et des bouts de l'application complète et ne changeront jamais tout d'un coup. Enfin, ça peut arriver en réalité, mais généralement c'est une nouvelle version qui va cohabiter avec une ancienne. Et le souci de cette Ausha, c'est que souvent, quand on a besoin de repartir de zéro avec un nouveau moteur et des technologies plus modernes, on ne peut pas répliquer à l'identique un logiciel qui existait depuis 20 ans et qui avait 20 ans de développement avec toutes ses fonctionnalités. Dans ces moments-là, on est obligé de trancher dans le vif, de sélectionner que les choses les plus critiques et les plus importantes dans la nouvelle version qui sera. fluide, rapide, modernisé, etc. tout très bien, mais qui perdra forcément un grand nombre de choses par rapport à l'ancienne. En partant du principe qu'on va vous mettre dans les mains la nouvelle version au top, et vous rajouter ce qui manque petit à petit. et que les bookings seront rajoutés petit à petit, ils seront mieux pensés, plus rapides et tout. Mais voilà, et ça c'est un des cas que j'ai déjà vu justement dans différentes boîtes où en fonction du client et de l'utilisateur final, ça va être « Ok, je préfère rester sur l'ancienne version, donc la nouvelle n'est pas assez mature, elle n'a pas ce dont j'ai besoin dans mon quotidien » ou au contraire, les fonctionnalités qu'il y a dans la nouvelle version, c'est juste ce dont j'ai besoin. Et c'est parfait, je peux basculer dessus. J'avais deux, trois broutilles que j'aimais bien raconter, mais je peux m'en passer pour le moment.
Manu
Parce que les langages aussi ont différentes versions. Et on ne peut pas juste, quand un nouveau, par exemple, un nouveau langage en Java sort, se dire, on fait la mise à jour et puis notre application, on passe au nouveau langage, à une nouvelle version de Java qui apporte des nouvelles fonctionnalités, des meilleures performances. Parce qu'il y a des choses qui ne marcheront plus. C'est un moment où on ne peut pas juste mettre à jour aussi facilement. Et c'est comme ça qu'on se retrouve. C'est ce qu'on appelle des refontes, quand on refait une partie. Et ça, c'est très connu, par exemple, dans le système bancaire, assurance. On va dire des boîtes qui ont des logiciels historiques. On va trouver peut-être encore des bouts de cobol aussi, qui est un très, très vieux langage.
Lulu
ça dans la banque c'est encore autre chose parce qu'ils sont un peu banque à l'aéroport etc ils ont des outils tellement critiques qui font durer et traîner des choses qui sont très technologiquement où il y a peu de gens qui sont encore en mesure de le réparer c'est
Manu
ça et puis des fois la refonte va prendre tellement de temps qu'elle sera déjà obsolète donc on se retrouve à faire des refontes de refontes et c'est sans fin donc voilà après ça c'est plus Aïe ! C'est à l'échelle vraiment d'une plus grosse boîte et tout ce qui est, on va dire, plus historique aussi. Automobile. Après, je pense que tu l'as peut-être rencontré dans des trucs plus récents, dans des contextes plus récents aussi.
Lulu
Oui, ce n'est pas forcément une taille de boîte, c'est vraiment plus une durée de vie du logiciel. Parce qu'en fait, tu peux avoir un petit programme qui est concerné, tout simplement, parce qu'il sera utilisé pendant 10 ans, pendant 5 ans, en plus. et pour lesquels, au bout d'un moment, il va y avoir certaines technologies ou certaines dépendances. On ne tirera pas là-dessus maintenant, mais dites-vous juste qu'un programme, quand vous le faites et quand vous le développez, vous ne développez jamais tout de zéro. Vous allez généralement vous appuyer sur des librairies, donc des bout de code qui ont été réalisés par d'autres, pour ne pas réinventer la roue à chaque fois. Mais la contrepartie de ça, c'est qu'il y a des briques qui peuvent ne plus être maintenues ou ne plus être compatibles avec des nouvelles versions. pour différentes raisons. Il peut y avoir des briques, justement, de dépendance qui se retrouvent avec des failles de sécurité dont on doit se passer pour aller sur quelque chose d'autre parce que les failles de sécurité ne peuvent pas être corrigées ou même si elles ont été corrigées, du coup, c'est un trop gros risque, etc. Enfin, il y a des considérations à prendre en compte. Il peut y avoir le fait de ne pas avoir pris de dépendance, d'avoir voulu coder soi-même une fonctionnalité et de se rendre compte qu'en fait, on n'était pas en mesure de bien la couvrir parce qu'elle était complexe techniquement. Il se retrouvait à utiliser des dépendances payantes ou des outils tiers qu'on va connecter aussi avec différents systèmes comme des API. Il y a plein de paramètres qui peuvent rentrer en jeu dans le fait de faire une refonte ou pas et que la refonte soit que sur des petits bouts, sur des grands bouts. On va prendre peut-être un exemple tout bon, mais aujourd'hui il y a beaucoup de logiciels et d'applications qui s'appuient sur Stripe qui fait toute la partie paiement. du coup ça devient une dépendance. Demain si Stripe pour une raison politique ou de sécurité ou comme ça, est plus compatible avec nos réglementations en France, du coup ça fait que toutes les boîtes qui s'habituent, elles l'ont dans l'offre, c'est qu'il faut soit qu'elles trouvent un autre équivalent à Stripe pour gérer toute la partie paiement de leur boîte, soit qu'elles développent eux-mêmes, et auquel cas c'est vraiment délicat parce que du coup dans les parties paiement il y a plein de choses qui sont vraiment... très sensible. Et puis même après, je pense qu'en termes réglementaires d'agrémenter tout, il y a des choses aussi à vendre. Mais voilà, pour citer un exemple de dépendance qui n'est pas une librairie pour le coup, qui est un outil tiers, mais qui est un outil tiers qu'on va intégrer et qui va être intégré dans plein plein de logiciels parce que c'est une brique tellement difficile à mettre en œuvre qu'on s'appuie sur de l'existant mais que cet existant a des contraintes.
Manu
C'est vrai que quand il y a eu aussi la mise en application du RGPD. Tout simplement, là, ça a demandé beaucoup de modifications, et là, c'est une réglementation qui évolue, et là, ça demande de mettre à jour, de rajouter des choses qui n'étaient pas prévues au départ dans un logiciel, et là, ça demande... Pas mal de boulot, je sais que ça a été compliqué dans pas mal de boîtes, la question RGPD. Oui,
Lulu
parce que le RGPD implique ne serait-ce que de pouvoir exporter tes données en tant qu'utilisateur. Donc en fait, il faut dans le logiciel en mettre en œuvre tout ce qu'il faut pour récupérer toutes tes données un peu partout et te permettre de les sortir de là, de les exporter, d'en avoir une copie complète. Et ils sont aussi censés te permettre de supprimer ou d'anonymiser en fonction des cas. peut être supprimé ou pas, parce qu'il y a des choses que techniquement tu ne vas pas pouvoir supprimer, mais du coup tu vas devoir basculer en anonymisation pour pas qu'on puisse remonter ta trace et en même temps que le logiciel continue à fonctionner. Quand elles sont reliées entre elles, si tu casses un bout, tu peux casser beaucoup de choses à côté, donc la suppression n'est pas si simple. Et après, en plus, tu dois rajouter d'autres contraintes, puisque notamment sur les parties RGPD, ça peut rentrer en contradiction avec d'autres règles de sécurité informatique en fonction de ton secteur et de la sensibilité, par exemple dans la santé ou d'autres domaines, la durée de rétention des données n'est pas la même. Et du coup, c'est toujours celle qui est en vigueur la plus critique, on va dire, qui va prendre le pas sur le RGPD et qui va le rendre caduque. Parce que si le RGPD te dit combien d'années il faut en standard pour la rétention des données, mais si d'un point de vue légal, on te dit que non, sur cet usage-là de santé, il faut garder les logs et la traçabilité pendant 10 ans. Pendant 10 ans, tu ne vas pas ni supprimer ni anonymiser parce que c'est une obligation légale d'avoir ces infos-là. Du coup, c'est des choses à prendre en compte, à mettre en œuvre d'un point de vue métier et d'un point de vue technique, ce qui peut amener plein de galères.
Manu
C'est là qu'on peut se rendre compte que c'est pertinent d'essayer au maximum de découper pour qu'on puisse presque y aller de manière chirurgicale pour modifier. Alors, ça ne sera pas possible de ne pas impacter et juste avoir des Legos qui sont fixés de manière, on va dire, simple, sans dépendance. Mais à un moment, il faudra quand même impacter d'autres fonctionnalités. Mais si c'est bien découpé, ça se passera mieux que si c'est un gros mélange où il faut se dire, si je modifie là, qu'est-ce que ça va casser autour ? mais en même temps, si je casse tout ça, est-ce que c'est... plus grave que de ne pas être en conformité.
Lulu
C'est là que typiquement, avoir une base de données bien structurée est fondamentale. Parce que tes éléments vont quand même être liés les uns les autres entre les différentes tables, entre les différentes entités d'information. Mais plus cette structure est efficiente, plus justement tu vas pouvoir identifier les infos qui vont bien, jongler d'une relation à une autre pour prendre ce que tu as besoin ou justement supprimer ou analyser ce que tu as besoin. sans tout casser. Et là où, comme on disait au tout début, comme le cas de l'adresse ou ce genre de choses, si c'est un seul tenant, un seul bloc d'informations, et dedans vous avez une info à enlever, mais qu'en fait, si vous enlevez cette info, vous êtes obligé d'enlever l'entièreté de l'adresse. Sinon, on va prendre l'exemple de l'adresse. Mais en fait, dans votre adresse, vous n'êtes plus à l'étage, vous êtes au rez-de-chaussée. Et si c'est un seul tenant, vous cassez toute l'adresse, vous supprimez toute l'adresse. Dans notre cas, vous allez juste mettre à jour une information de moi.
Manu
Ça ou par exemple si l'adresse c'est un seul bout, de se dire, je ne sais pas, demain il y a la réglementation qui change et les codes postaux changent. Ça peut être pratique que le code postal soit isolé tout seul et qu'on n'ait pas à remodifier tout et peut-être essayer de l'isoler alors que tout est imbriqué. Je pense que ça a été un peu le cas avec ce qui se passait avec le RGPD. penser aussi dedans comment est-ce que notre chemin de données, comment est-ce que c'est stocké, comment est-ce que les données sont séparées, comment est-ce que les rends accessibles...
Lulu
Et même d'ailleurs, aujourd'hui, quand tu fais un programme de zéro, si tu ne penses pas à ta conformité à RGPD au début, on ne va pas se mentir, c'est chiant.
Manu
Comme l'accessibilité, c'est à penser dès le début et pas à la fin.
Lulu
Oui, clairement. Allez, on embraye. On a bientôt fini, si vous êtes encore avec nous. on est presque alors on va terminer plus rapidement donc suite au test on a fait tout le panel et on va revenir au fameux concept de mise en production de quoi on parle ? Quand on développe alors on va avoir une structure classique, encore une fois selon les boîtes il peut y avoir plus ou moins d'environnement mais là le standard ça va être de se dire on a trois environnements, un qui est là pour le développement Donc c'est là où vos équipes de développement, vos développeurs et développeuses vont faire justement les différentes briques de code dont on a parlé tout à l'heure et leurs différentes versions, leurs PR, et balancer tout ça quelque part et ça arrivera généralement en dev. où vous avez la version de votre Google Doc dont on parlait tout à l'heure, de votre document complet. Vous avez la version la plus à jour, la plus fraîche, mais celle qui est aussi le plus fragile parce qu'elle a eu des tests unitaires, etc. Elle peut avoir plus ou moins de tests end-to-end et tout, selon le process de la boîte, mais elle est dans un environnement qui est prévu pour être cassée, en quelque sorte. OnDev, c'est vraiment votre environnement de bordel. Au-dessus, vous allez avoir... L'environnement dit de staging ou de pré-production, ça peut être deux environnements différents. Vous pouvez avoir un environnement dit de recette, un environnement de staging. Là, vous pouvez avoir plusieurs paliers, mais si on part du principe que vous en avez qu'un, c'est un environnement de pré-production. En gros, lui, il est là pour ressembler le plus possible à votre production. L'environnement de production étant celui que vous, vous avez dans les mains en tant qu'utilisateur et utilisatrice. Mais en fait derrière un environnement de production, ou un environnement des autres, il y a plus que juste l'écran et le bout de code, il y a aussi toute la partie infrastructure. Parce que concrètement, votre équipe de développeurs, s'ils sont 5, du coup ils n'ont pas besoin d'avoir énormément de ressources matérielles derrière pour faire tourner l'application. Ils n'ont besoin que d'une version légère. Mais en revanche sur la production, si vous avez 10 000 utilisateurs, il faut que derrière vous ayez des serveurs des ordinateurs, des machines, un réseau des mesures de sécurité des tests, des sauvegardes etc qui soient proportionnés pour supporter ces 10 000 utilisateurs et en fait le staging va être l'entre-deux votre environnement de pré-production il va être déjà plus sécurisé plus vérifié que l'environnement de dev il peut avoir éventuellement des données enfin pas pas forcément issus de la production, mais en tout cas qui reflètent des données de production, qui sont des données plus complètes, là où on dev, on va avoir un peu plus de données vraiment de tests, de brouillons, on va aussi avoir des vraies applications pour s'entraîner, mais voilà, qui va être un peu à part. Et votre staging, donc, c'est vraiment l'hybride de se dire, il doit ressembler le plus possible à la production en termes de type de données, en termes de type d'exemples, en termes de profil utilisateur, en termes de pas de nombre de gens, ça ne pourrait jamais répliquer autant, ou alors si, d'ailleurs je dis ça, mais il y a des tests qui permettent de le faire, mais voilà, c'est votre entre-deux, et justement, la fameuse mise en production, c'est de se dire, ok, donc sur staging, on a tout qui est bon, tout a été testé par le service qualité, tout est arrivé jusque-là, on s'est rendu compte aussi que sur notre environnement de staging, qui ressemble le plus possible à la prod, entre dev et là, on a eu un problème quand on est passé de l'un à l'autre, problème de déploiement, de... où, en fait, quand on a mis à jour, on s'est rendu compte qu'il y a un truc qui ne s'est pas bien passé côté infrastructure, parce qu'il y avait un tunnel qui était bouché, ou parce qu'il y avait un truc de réseau qui ne marchait pas bien, ou parce qu'il y avait une fonctionnalité qui marchait bien dans l'environnement de développement, mais en fait, sur l'environnement de pré-production, on se rend compte qu'il y a un truc qui ne passe pas et que, je ne sais pas moi, les administrateurs par exemple, peuvent plus se connecter à l'application. Voilà, c'est ce genre de choses qu'on va pouvoir identifier quand on passe d'un environnement à l'autre. Et l'idée, c'est qu'en staging, on verrouille tout ou quasiment tout, pour que quand on envoie en production, donc quand on fait la fameuse mise en production, le programme arrive, prêt, il tourne. On sait là où il peut y avoir des pépins et on est prêt à les corriger dans la foulée. On a vérifié que tout ce qui était critique est bon. On fait de la surveillance et on garde le tout à l'œil. Et pendant la mise en production, c'est le moment où les équipes sont au taquet, prêtes à intervenir. pour soit corriger les pépins s'il y en a au moment où ça arrive la mise à jour est terminée soit si, c'est le pire scénario, si la mise à jour elle casse tout et qu'on n'arrive pas à débloquer le cas, de pouvoir faire ce qu'on appelle un revert enfin revenir à une version antérieure et ça pareil, il y a plein de manières de revenir, enfin plusieurs manières en tout cas de revenir à la version antérieure mais de s'assurer que la production elle est coupée le moins longtemps possible si jamais elle doit avoir un mètre. Et j'ai parlé de recettes sans expliquer ce que c'était, mais en fait la recette ça va être un peu l'ensemble des scénarios qu'on doit valider avant d'envoyer en production. Donc de se dire, on a un panel de tests, où il y a, je viens de bêtise, 1000 tests possibles, et on va estimer que ces 1000 tests doivent être remplis avant d'envoyer en production, ou alors on va estimer qu'il n'y en a que 700 qui sont nécessaires, ou 300, etc. Après ça, ça va dépendre un peu d'eux. la tambouille de chaque boîte, le niveau de complexité, la criticité aussi de la mise à jour. En fait, il y a des mises à jour qu'on va envoyer en production et sur lesquelles on sait qu'il y a peu de risques et donc un panel de recettes plus léger peut être raté. accepté et ben nécessité moins de temps, moins de risques etc. Là où ben en fait justement si on a fait une refonte plusieurs refontes de se dire ah oui mais non là il faut vraiment que tout tout soit vérifié jusque le plus possible pour qu'on ait le moins de pépins possible arrivé. Voilà dans l'idée sur les trois gros environnement est ce que représente une mise en production et raison pour laquelle on évite de la faire le vendredi parce qu'en cas de pépins vous vous flinguez un bout de week-end Voilà, ça c'est dans les pires cas. Et de manière générale, une des bonnes pratiques de mise en production, c'est de le faire en dehors des horaires où vos utilisateurs sont sur l'application. Et scénario, encore idéal, si jamais vous êtes obligé de le faire, enfin le coquin n'est pas idéal, mais si jamais c'est obligé de le faire pendant des heures d'ouverture où les gens sont là, parce que ça va prendre trop de temps de faire les changements, quand il y a des grosses refontes, etc. On peut avoir un temps de coupure qui est absolument nécessaire. Et dans ces cas-là, on prévient à l'avance de se dire « Attention, ce jour-là, de telle heure à telle heure, il peut y avoir des perturbations parce qu'on met une nouvelle version. » Ou alors « Pendant de telle heure à telle heure, le produit sera juste complètement indisponible. » Et voilà, prenez vos mesures et soyez attentifs à ça. Et ce jour-là, vous pourrez. Aujourd'hui, même chose en fonction du domaine et du niveau d'importance de l'application. généralement il y a aussi des... je vais pas voir le terme mais en gros il y a tout un plan qui enfin il y a un nom pour les plans qui permettent de fonctionner en mode dégradé et donc quand justement l'application est pas disponible en entièreté ou est coupée pour x raisons de quand même pouvoir faire tourner le programme dans une manière plus légère pour pouvoir bosser parce qu'on peut dire en fait ce jour là j'ai des fonctionnalités qui marchent pas mais au moins je peux bosser de bout en bout et ça théoriquement il faudrait avoir ce concept-là dans toutes les boîtes, de se dire, est-ce qu'il y a un mode dégradé dans l'application que j'utilise qui me permettra de bosser dans tous les cas ? Et si jamais ce n'est pas le cas, est-ce que j'ai un plan B, tout simplement ? J'ai des outils de secours qui vont me permettre de bosser ? Je ne sais pas si tu as le terme en tête, Lulu, pour le plan de...
Manu
Non, je ne l'ai pas forcément, mais...
Lulu
Bon, j'essaierai de remettre la note dessus. En plus, il y en a quelqu'un dans la communauté de code qui... qui est spécialisé sur le sujet, qui en avait déjà pas mal parlé et fait du contenu dessus, mais je peux avoir l'appel à ça. Est-ce qu'on est bon sur la mise en production ? Et comme ça, on termine très rapidement pour la partie maintenance.
Manu
Ouais, ça me semble bien. Là, je pense que vous avez compris pourquoi est-ce que on développe pas sur la partie qui est en prod. Je pense que là, c'est à peu près bon. Est-ce que on connaît, tout le monde connaît quelqu'un qui le fait, qui l'a fait ? C'est d'autant plus vrai. à l'ère du vibe coding et développement par IA ou même l'application qui est en ligne et de se dire je vais juste faire un petit fixe,
Lulu
je vais juste changer un petit truc et au final ça casse tout et c'est plus accessible c'est effectivement le vibe coding donc le développement assisté par IA que même si vous bossez seul même si vous bossez, d'autant plus normalement si vous bossez en équipe vous avez déjà les bons réflexes mais si vous bossez seul et que vous découvrez prenez le temps de vous former sur les les méthodes et les techniques de développement, et ne serait-ce que, parce qu'en fait, ça s'applique aussi. Alors, vous n'êtes pas obligé d'avoir un staging au milieu, mais en fait, vous avez quand même besoin d'éprouver ce que vous faites sur un environnement de développement, donc généralement en local, sur votre machine, et ensuite de l'envoyer en production, donc vraiment sur la partie que les gens utilisent. Mais aussi, dans le vibe coding, il y a moyen d'avoir des environnements de pré-production. Par exemple, sur Supabase, qui est un outil qui fait back-end, donc base de données, authentification, plein de choses, permet d'avoir des branches qui sont conformes d'un point de vue infrastructure avec la production. Et du coup, vous pouvez soit faire vos tests en local, puis envoyer directement sur la prod une fois que c'est validé, soit faire vos tests en local, puis passer par une branche dite de preview et de là envoyer vers la production, soit faire un espace d'hybride où vous faites vos tests. directement sur la branche de preview, vu qu'elle est prévue pour ça, dans tous les cas. Et voilà, il y a plusieurs approches, mais en tout cas, même en white coding, et différents outils le permettent, Gano le permet, enfin, voilà. Il y a plusieurs approches, mais en tout cas, la notion d'environnement et de ne pas bosser directement sur ce que les gens ont dans les mains est fondamentale. Et après tout ça, donc, dernier point, dernière étape, votre application est en production. les gens s'en servent, la dernière chose qui reste, c'est la maintenance et le support. C'est là où on va repartir un petit peu dans un cycle comme on a... On va refaire un peu tout le cycle, en fait. C'est-à-dire que les gens vont vous signaler des soucis, soit des bugs, soit des choses qui seraient bien de faire évoluer, soit des choses qui manquent et qui auraient besoin de nouvelles fonctionnalités. Et ça va repartir dans l'étape recueil du besoin pour comprendre tout ce qu'on vous demande. Est-ce que c'est pertinent ou pas ? Comment on peut le faire ? Comment on peut le traduire ? Quand c'est le cas d'un bug, est-ce qu'il est important, pas important ? À quel niveau ? qu'est-ce que ça implique comme effort de développement pour le réparer rapidement ou pas. Et ça repart dans tout le cycle derrière, de développement, de relecture, de test, des différents environnements, etc. Et c'est pour ça que, de toute façon, même si un bug est corrigé le jour même, ça ne veut pas dire que vous l'aurez le jour même, parce qu'il faut qu'il repasse par toutes les étapes. Et qu'on ne fait pas une mise en production à la légère. Donc vous avez besoin... d'attendre généralement d'avoir plusieurs choses qui sont prêtes et développées en même temps avant de faire une mise en production. Et selon les boîtes, vous pouvez avoir une mise en production chaque semaine, chaque deux semaines, chaque mois, chaque deux mois, enfin du coup c'est très variable. Mais c'est ça le principe. Et sachant que chaque correction que vous pouvez faire peut vous amener d'autres effets de bord et d'autres problèmes à côté. D'où l'importance des tests et de chaque étape qu'on a citée au paradis. Et c'est aussi pour ça que dans les boîtes, vous aurez généralement les équipes de support. Et pour avoir bossé dans le support dans pas mal d'années et dans plusieurs boîtes, je vous confirme que généralement, les équipes de support sont celles avec les équipes de qualité qui connaissent le mieux le produit dans son entièreté, parce qu'elles sont amenées à travailler au contact des gens et des retours utilisateurs directement, donc au contact des métiers, un terme qu'on a déjà évoqué pas mal de fois, et en même temps qui manipulent un petit peu. tout le programme de bout en bout et donc ils sont les plus à même de dire et de savoir il y a ça qui ne marche pas mais en même temps on a une nouveauté à tel endroit qui doit pouvoir impacter ici ou alors il y a peut-être un contournement par tel biais et ainsi de suite et voilà d'où l'importance aussi de la communication entre les différents services dans les boîtes parce que au développement et d'autant plus quand la boîte va être plus grosse et le produit plus volumineux et qu'il va commencer à avoir de... du legacy, donc du code qui est hérité parce que le programme a 5 ans, 10 ans, 15 ans, 20 ans. C'est impossible d'avoir tout en tête à chaque fois qu'on fait quelque chose, peu importe le service. Et à ce titre-là, c'est de la communication entre les différents services qui va déterminer la qualité de votre produit et de votre application. Parce que si les infos transitent et que le support est en mesure de vous remonter, les choses qui vont et qui ne vont pas, et là où les utilisateurs râlent le plus, ou les pépins qu'ils ont le plus, la qualité... quand ils font les tests, si vous écoutez ce qu'ils vont vous dire et les évolutions et les ajustements qui seraient intéressants, c'est vraiment fondamental aussi et après les devs aussi ont leur mot à dire parce qu'ils sont complètement en mesure d'identifier quand il y a des problèmes de performance quand il y a des problèmes de des suggestions dites du hits par exemple un développeur qui va vous faire toute l'interface même si elle a été maquettée par un designer et par quelqu'un d'autre, peut très bien vous dire en fait là non vous m'avez donné ça comme consigne et je suis censé faire tel écran, mais en fait, il y a des choses pour moi qui ne vont pas à l'utilisation, ça va coincer pour telle et telle raison. Et voilà, donc à mon sens, la base d'une bonne application, ce sera la communication entre les différents intervenants d'un programme, de bout en bout, et de tenir compte du fait que chaque étape est importante et chaque personne que vous avez à chaque étape est importante.
Manu
Et c'est vrai que j'avais vu certaines boîtes justement où... Parfois, on peut avoir l'idée que les devs sont un peu déconnectés de ce qui se passe et comment le produit est utilisé. Et justement, de faire tourner les devs aussi sur le support pour qu'ils soient au contact des utilisateurs et de se dire, ça fait une, deux fois qu'on me demande ça. Bon, je n'ai pas envie qu'on me redemande la prochaine fois, donc je vais le corriger. Et ça peut donner d'autant plus de sens à un geste qui va être soit correctif, adaptatif ou perfectif. Ça, c'est les différentes modifications qu'on peut faire. Mais c'est là où c'est intéressant de pas juste rester cloisonné. C'est vrai que c'est quelque chose qui est assez français, de cloisonner les différents métiers, les différentes compétences. Là où, par contre, par exemple, aux États-Unis, ils vont plus travailler par feature. Donc là, ça va être vraiment, on va travailler sur une fonctionnalité et... Il y a du bon et du moins bon dans chaque modèle, mais parfois, on peut manquer un peu de prise de hauteur et de se dire comment est-ce que ça s'intègre. tout le parcours parce que forcément chaque... compétences, chaque personne va avoir un biais par rapport à ce qu'il fait et de se dire, moi c'est plus important alors que le support va dire autre chose, le développeur va dire autre chose et en même temps, côté marketing ils vont encore dire autre chose et voilà, il faut réussir à faire communiquer tout ça et encore une fois la communication, de s'ouvrir aussi même sans forcément savoir le faire et que ça devienne nos compétences, là c'est un peu ce qu'on essaye aussi de faire avec cet épisode, de donner les clés pour pour pouvoir communiquer avec quelqu'un qui le fera ou si on a envie de se mettre à développer, d'avoir ce qu'il faut en tête pour avancer et apprendre.
Lulu
Oui, et là, on n'a pas détaillé toutes les méthodes parce qu'on vous en doutait. Là, on vous a donné les grandes lignes de choses qui reviennent à chaque fois dans un développement d'application. Mais il y a plusieurs méthodes de le faire, plusieurs méthodes de travail en équipe, il y a plein d'organisations, il y a plein de... Et voilà, comme on l'a dit, en fonction de la taille de boîte, en plus, ça va jouer. Mais ce qui est important de retenir, c'est les différentes étapes qu'on vous a données aujourd'hui pour que vous ayez en tête que quand quelqu'un fait un programme, qu'il soit tout seul ou que ce soit une équipe de 10 ou de 20 ou de 2000, derrière, ce n'est pas juste j'ai besoin de ça et on le couche sur un écran une journée. Même quand c'est rapide, même quand c'est tout seul avec du développement assisté parier, etc. Il y a tout un cheminement à avoir, toute une logique à avoir si on veut faire les choses bien. Et c'est là où il faut être aussi méfiant et vigilant quand on fait du vibe coding. Ça ne veut pas dire qu'il ne faut pas faire de développement assisté par IA, ça ne veut pas dire que tout ce qui est fait en vibe coding sera mauvais ou sera bon, parce que si il est fait, il le fera bien et tout. On a déjà évoqué le sujet, l'IA reste un outil. Potentiellement un très bon exécutant, mais derrière, c'est à vous de driver et d'avoir en tête le chemin justement et les logiques. Je j'ose espérer. En tout cas, je vous souhaite que la prochaine fois que vous discutiez avec quelqu'un de votre boîte ou un collègue ou de la famille ou des amis qui bosse dans un des services qu'on a évoqués aujourd'hui, ce soit un peu moins obscur pour vous de savoir quel rôle il a dans le chemin d'une application en tout cas. Même si effectivement, on n'est pas rentré dans le détail de chaque service.
Manu
C'est de se dire que ce sont les grandes étapes d'un logiciel, mais après, ça peut être aussi une partie dans le logiciel. Et c'est là où on va justement arriver sur différents modèles, juste rapidement. Parce que je pense que tout le monde connaît l'agilité, la méthode agile. C'est vrai qu'on n'en a pas forcément parlé, mais là, ce qu'on a un petit peu décrit, c'est la méthode en cascade. même si c'est pas forcément celle qui qui me marche le mieux si on le fait à l'échelle d'un logiciel parce que là, c'est ok, on met des besoins, on développe, on développe, et puis à la fin le client, il a quelque chose et c'est potentiellement pas forcément ce qu'il attendait, donc c'est là où il...
Lulu
En fait, avec une approche itérative, t'as quand même ces cycles-là, d'une manière ou d'une autre.
Manu
Oui, mais en plus petit.
Lulu
Enfin, c'est... Ouais, en plus petit.
Manu
Sur un périmètre peut-être plus petit aussi. C'est ça, sur ton périmètre.
Lulu
c'est-à-dire que tu ne vas pas attendre 6 mois avant de donner ta première version, tu vas le faire, comme je disais, ça peut être une fois par semaine, toutes les deux semaines, tous les un mois, selon la taille de boîte et selon les versions. Mais ce cycle-là de développement, de test, de mise en prod, etc., tout ça, il faut quand même y passer, le recueil des besoins aussi. Mais c'est vrai que dans la partie itérative, quand on va penser une nouvelle fonctionnalité, le recueil des besoins, on va le faire différemment. On va aller discuter avec les gens, on va aller faire... des fois des maquettes ou des prototypes qu'on va leur mettre dans les mains, qui ne seront pas dans la version finale que tout le monde utilise, mais qui seront réservées à un petit groupe d'utilisateurs et d'utilisatrices qui vont pouvoir utiliser cette version-là un peu bricolée et dire « en fait, ça, ça marche bien, ça, ça ne marche pas bien » . Et à partir de là, on va développer la vraie version qui sera intégrée au logiciel. Et dans les parties recueil de besoins, justement, ça va être plus ou moins long. Dans la partie développement, ça va être sur le prototype qui sera plus ou moins gros, qui sera intégré à une prochaine version. En tout cas, les grandes étapes sont là, même en mode itératif et même avec d'autres approches, mais effectivement avec des durées différentes, avec des périmètres différents et avec des actions qui peuvent être un peu différentes aussi.
Manu
Il n'y a pas une méthode qui est meilleure que les autres. Ça va vraiment dépendre du type de logiciel développé, du type d'équipe. Il y a même des moments où la cascade ou le cycle en V reste pertinent par rapport... à une méthode agile, même mal appliquée, où on va faire un peu d'agilité de façade, ou du scrum. Il y a certains... contextes, notamment réglementaires ou alors qui vont toucher à toute la partie hardware, qui vont faire qu'un framework de développement sera plus pertinent qu'un autre. Donc c'est pas genre, si je me mets à développer, il faut forcément que ce soit avec une méthode agile. Il faut aussi se poser ces questions, c'est comme un peu dire il y a un meilleur outil qu'un autre, il y a un meilleur langage qu'un autre pour développer. A chaque fois, c'est en fonction, c'est qu'un outil qui va répondre. qui va aider à répondre du mieux possible à un besoin. Comme il y a, voilà, si elle peut être pertinente, c'est bien, mais ce n'est pas forcément une finalité.
Lulu
Oui, on est vraiment d'accord. Bon, on a fait notre plus gros et plus long numéro jusqu'à présent, mais au moins, vous avez le chemin complet. J'espère que ça vous aura plu.
Manu
Il y a toute la partie sécurité aussi, mais ça, on peut le mettre dans les tests. Il y aurait, mais après,
Lulu
il y aurait... Mais voilà. Le bon logiciel, ce n'est pas infini, mais oui, il y aurait la partie sécurité, il y aurait la partie sauvegarde, mais tu as d'autres choses dans la maintenance, dans le support.
Manu
C'est ça, mais ça, c'est comme on a dit pour les tests, il faut aussi la penser à chaque étape. Ce n'est pas à la fin, on vérifie que notre application est sécurisée. On va demander à Cloud Code, on vérifie si l'application est sécure et que c'est bon, les gens peuvent effectuer des paiements, créer des comptes sans souci dessus. Non, c'est aussi à chaque étape et ça inclure aussi dans les tests.
Lulu
Parfait. Merci Lulu de m'avoir accompagné sur cet épisode. On se retrouve la semaine prochaine pour la suite de notre épisode côté outils sur le développement de notre portail. Maintenant qu'on vous a expliqué tout ça, ce sera beaucoup plus simple à suivre. Et rassurez-vous, l'épisode sur la suite du portail sera plus court.
Manu
J'espère qu'il sera plus court maintenant qu'on a pris le temps de tout expliquer. Oui, on a déjà fait une première moitié. pour vraiment aller montrer comment on a mis les mains dans le cambouis et puis avec des côtés, enfin outils là pour le coup.
Lulu
Oui.
Manu
Voilà.
Lulu
Merci à tous et à toutes de nous avoir écoutés. On vous souhaite une bonne journée ou bonne fin de journée selon quand vous nous écouterez et on se retrouve la semaine prochaine avec Lulu.
Manu
Salut.

Chapters

À l'ère du vibe coding, tout le chemin derrière un logiciel
10sec
Le recueil des besoins : métiers, existant, fonctionnel et non-fonctionnel
4min
Conception : PRD, user stories et le découpage en briques
20min
Développement et versionnage : Git, GitHub, branches et pull requests
30min
Les familles de tests, la dette technique et les refontes
44min
Mise en production, maintenance et modèles de développement
1h14

About Le Dernier Clic (avant la fin du monde)

Le Dernier Clic c'est un podcast Tech, IA et No-Code où on prend un moment pour se poser sur les sujets tech et réfléchir à ce qu'on en fait.

A une époque où tout va trop vite, où la tech est politique et l'IA une révolution industrielle, on discute de ce qui se passe pour mieux comprendre les enjeux et garder la main sur notre dernier clic avant la fin du monde.

On alterne chaque semaine : un épisode thématique où on creuse un sujet, et un épisode orienté outils, où on vous parle de ce qu'on utilise vraiment au quotidien et pourquoi.

Nous sommes Lucile Mothiron et Emmanuel Fernandez, deux adeptes de la tech quand elle est utile, ravis de vous embarquer avec nous pour cette première saison du Dernier Clic.

Hébergé par Ausha. Visitez ausha.co/politique-de-confidentialite pour plus d'informations.

About Le Dernier Clic (avant la fin du monde)

Le Dernier Clic c'est un podcast Tech, IA et No-Code où on prend un moment pour se poser sur les sujets tech et réfléchir à ce qu'on en fait.

On alterne chaque semaine : un épisode thématique où on creuse un sujet, et un épisode orienté outils, où on vous parle de ce qu'on utilise vraiment au quotidien et pourquoi.

Nous sommes Lucile Mothiron et Emmanuel Fernandez, deux adeptes de la tech quand elle est utile, ravis de vous embarquer avec nous pour cette première saison du Dernier Clic.

Hébergé par Ausha. Visitez ausha.co/politique-de-confidentialite pour plus d'informations.

Description

Git
Formation Git
Github

00:12 - À l'ère du vibe coding, tout le chemin derrière un logiciel

04:40 - Le recueil des besoins : métiers, existant, fonctionnel et non-fonctionnel

20:47 - Conception : PRD, user stories et le découpage en briques

30:40 - Développement et versionnage : Git, GitHub, branches et pull requests

44:47 - Les familles de tests, la dette technique et les refontes

1:14:03 - Mise en production, maintenance et modèles de développement

Retrouvez nous sur :

https://www.instagram.com/ledernierclic/

https://www.linkedin.com/in/emmanuel-fernandez-b28740180/

https://www.linkedin.com/in/lucile-mothiron/

contact@ledernierclic.fr

Hébergé par Ausha. Visitez ausha.co/politique-de-confidentialite pour plus d'informations.

Transcription

Manu
Bonjour et bienvenue dans Le Dernier Clic, votre podcast tech, IA et no-code. On se retrouve comme chaque semaine avec Lulu. Comment ça va ?
Lulu
Ça va bien.
Manu
Et d'ailleurs, je ne te m'en ai pas demandé s'il ne faisait pas trop chaud chez toi. Tu n'étais pas encore en mode caniculaire.
Lulu
Oui, je suis venue, c'est signé. comme toujours, mais bon, on arrive à garder du frais à la maison, donc ça va.
Manu
Parfait. Alors, on se retrouve cette semaine pour changer un petit peu des sujets d'IA, parce qu'on vous a pas mal parlé d'IA ces dernières semaines et ces derniers épisodes, notamment sur l'IA frugale et la semaine dernière quand on vous a parlé également de notre portail. Donc, on est revenu en fait un petit peu sur ce que ça implique de développer une application en l'illustrant à travers le développement de notre application, de notre portail qu'on utilise, nous, au quotidien maintenant pour préparer nos épisodes. C'était un épisode côté outils un petit peu thématique et un peu plus particulier. Je vous invite à l'écouter si ce n'est pas déjà fait et si le sujet vous intéresse. Et aujourd'hui, histoire de faire le pont justement avec tout ça et de clarifier un petit peu ce que représente le développement logiciel, le développement d'une application au sens un peu plus général. qui n'est pas spécifique au wipecoding et au développement assisté par IA, qui n'est pas spécifique non plus à la manière dont nous, on travaille avec Lulu et ce qu'on vous a présenté la semaine dernière et ce qu'on continuera de vous présenter la semaine prochaine. Là, l'idée va être de revenir un petit peu sur le développement logiciel au sens large. Lulu, je te laisse nous dire un petit peu pourquoi aussi on part sur ce sujet-là maintenant.
Lulu
En fait, on s'était dit... Peut-être qu'on continuera juste à parler du développement dans cet épisode-là, mais moi, en tout cas, ça me semblait important de juste prendre le temps de définir les différentes étapes et de revenir un peu sur le vocabulaire aussi. Parce que c'est peut-être des expressions qu'on voit beaucoup dans notre bulle, mais sans forcément comprendre ce que ça implique de faire des tests, sachant qu'il y a différents tests, même les différents types de développement. Bon, là, on n'ira pas. pas beaucoup dessus. On a essayé de condenser pour donner un vernis et une première couche de vocabulaire et savoir ce que ça veut dire quand une application est en prod, le côté maintenance, vraiment toutes les grandes étapes de développement. On est dans de la vulgarisation, on sait que c'est différent plus ou moins dans chaque boîte, mais là, c'est des grandes étapes. dans la théorie et a priori, on passe par celle-là.
Manu
Oui, on va effectivement, on va revenir vraiment sur les principes et que vous soyez exposé en fait déjà ou pas au jargon et à certains mots qu'on emploiera. L'objectif là justement, c'est que ce soit clair pour tout le monde. Parce que bien souvent, quand on croise des gens dans les boîtes, même si votre entreprise est un éditeur de logiciels et qu'elle va le mettre à disposition de clients pour une fonction Voilà. pour un usage spécifique ou des usages spécifiques, au sein d'une entreprise, il est quand même assez fréquent de voir que les gens ne se rendent pas forcément compte de ce qui se passe dans les autres services et du rôle de chacun et du rôle de chaque équipe au niveau d'un produit, au niveau d'un logiciel. Donc on n'ira pas justement dans le détail de tout, comme disait Lulu, puisque en fait, en fonction de la taille de l'entreprise, déjà, ça va impacter différemment et avoir des... comment dire... des dépendances et des sujets plus ou moins vastes et des implications techniques plus ou moins vastes. On ne va pas revenir sur tout ça parce que ce serait infini, mais bien vous donner les clés de compréhension de ce qu'est un logiciel, vraiment de bout en bout, en tout cas sur toutes les phases principales et importantes.
Lulu
Ça dépend du type de logiciel aussi qui va être développé. Il y a autant de spécificités presque de logiciels et d'équipes. C'est des grandes phases aussi pour savoir ce que ça implique parce qu'on a l'impression qu'avec l'IA, tout est simple et on peut tout aussi bien se lancer soi-même dans le développement ou passer par quelqu'un qui développera. Et je pense que c'est important d'avoir ce vocabulaire qu'on soit potentiellement client ou une personne qui va se dire « bon, je peux faire un logiciel maintenant juste en comptant » . C'est bien de savoir tout ce que ça implique.
Manu
Parce que typiquement quand vous avez un produit dans les mains, un logiciel dans les mains, il n'y a pas juste eu une étape où vous avez dit je veux tel truc, je veux un programme qui me fasse ces trois fonctions et quatre boutons, et basta, il y a tout un chemin à parcourir pour arriver à deux. du début à la fin. Et le début de ce chemin, en fait, il va passer par ce qu'on appelle le recueil des besoins. On l'avait déjà évoqué la semaine dernière, un petit peu, à travers la compréhension des besoins pour notre cas d'usage qui était le portail. On s'est dit, ben voilà, nous, aujourd'hui, on a des infos éclatées dans plein d'outils, on a besoin de tout centraliser, et que ça nous aide à faire un épisode de tout en bout. Et pour ce faire, ben voilà, que ce soit sur un usage comme le nôtre ou sur n'importe quel usage, vous allez avoir besoin de comprendre et... d'interagir et d'aller chercher les informations pour ce fameux recueil de besoins. Est-ce que tu peux nous l'expliquer un peu, Lulu, sur les différentes approches qu'il peut y avoir, justement ?
Lulu
Oui, et juste aussi, on en avait parlé dans l'épisode sur l'Igafrugal, où déjà de bien définir, savoir si ce qu'on veut développer n'a pas déjà une solution, de bien répondre à un problème, parce que si on se lance tout de suite dans le développement du logiciel, on peut le faire de la meilleure manière possible, s'il ne répond pas. à un problème ou à une douleur, il ne va pas forcément servir et ce sera toutes les étapes derrière qui vont juste partir à la poubelle où le logiciel ne sera pas utilisé. Et c'est important, déjà pour recueillir du besoin, et il faut aller chercher du concret, donc en général, ça passe par des phases de discussion avec des vrais gens qui, idéalement... ont ces problèmes au quotidien, ou des frictions, ou ils connaissent un peu leur process. Alors là, c'est peut-être plus dans un cas de... Comment dire ? Pas que d'outils internes, parce qu'après, je pense que c'est encore différent en startup, quand tu développes un produit. Toi, tu connais peut-être un peu plus du côté là, mais on va avoir des entretiens, on va les observer, étudier l'existant, que ça soit un logiciel déjà existant. ou savoir comment les gens travaillent. Et nous, pour mettre en parallèle, c'était un peu toute notre phase de bricolage, savoir par où passer l'information et qu'on ait un peu une idée des flux. Je ne sais pas si toi, peut-être par rapport à ton expérience...
Manu
Alors, déjà, effectivement, normalement, le besoin d'une application, le besoin d'un logiciel, il l'est habituellement et théoriquement, il émerge tout seul. Il va émerger tout seul d'un problème que... Quelqu'un dans son entourage va rencontrer, et dans son entourage que ce soit perso ou pro, mais disons qu'on est dans un contexte d'entreprise, donc ça va être des collègues qui vont commencer à se plaindre d'avoir besoin de quelque chose pour arriver à leur fin. Pour produire un document, par exemple, de travail, ils n'ont pas les informations qu'il faut, ou alors ces informations, ils sont obligés, comme nous, d'aller les chercher dans 15 endroits différents, ou alors ils n'ont techniquement rien qui leur permette de produire le livrable dont ils ont besoin, que ce soit un document, que ce soit un PDF, que ce soit un... pas importe le livrable final, quelque part, le besoin, il part de là. Et donc ça, c'est une approche de recueillir tout simplement ce qui a été constaté dans une boîte. Donc soit parce que la solution n'existe pas, soit parce que la solution, aujourd'hui, elle a été bricolée. C'est pour ça qu'on a beaucoup de gens qui utilisent du Excel et qui le détournent ou qui utilisent d'autres outils qu'ils ont à disposition dans l'entreprise et qui vont gruger un petit peu comme ils peuvent dans les différents bouts. pour les tordre au mieux et arriver à leur fin. Parce qu'à partir du moment où ils n'ont pas l'outil adapté, il faut quand même réussir à bosser. Et ils vont employer un petit peu tous les moyens à leur disposition pour y arriver. Et après, il y a le contexte d'éditeurs de logiciels ou de startups, peut-être plus propres aux startups ou aux boîtes qui vont démarrer, qui vont identifier un besoin qui n'est pas encore couvert par le marché, soit qui est... partiellement couvert par le marché ou pas de la bonne manière ou alors, parce qu'en fait la plupart des besoins dans les boîtes ils sont là depuis très longtemps, c'est juste la manière d'y répondre qui va être différente et un point de vue, un angle, une façon de le faire, une technologie nouvelle, une interface plus simple enfin voilà, il y a plein de choses pour l'amener, mais qui va être de repenser le problème d'une manière différente. Si on prend des gros outils, pour essayer d'aller dans un peu plus de concret, des suites logicielles comme Word. ont apporté de la bureautique pendant très longtemps à travers le classique éditeur de texte, le tableur et le PowerPoint, l'éditeur de diaporama. Google a un peu renversé tout ça quand il a apporté le collaboratif à l'époque de Google Drive et de la suite Google. Donc d'un coup, on s'est rendu compte qu'on n'avait plus besoin d'installer ces programmes-là sur son ordinateur et que chacun ait sa licence et tout ça pour travailler. Mais on pouvait passer, même s'il y avait aussi un système de licence. mais on pouvait passer directement par des outils en ligne, via internet, sans avoir à rien installer, et quand même avoir du collaboratif où tout le monde travaillait en temps réel sur le même document, on voyait les gens interagir. Et voilà, ça a été une nouvelle façon déjà d'appréhender la suite bureautique avec un aspect neuf. Et Notion, prononcez-le comme vous voulez, l'a apporté encore d'une manière différente plus tard, avec cette idée de partir d'une page blanche, d'avoir un header qui soit beaucoup plus simple qu'un Word, et en même temps d'intégrer dedans des petites bases de données qui ressemblent à des tableaux, donc c'est assez familier pour qu'on les prenne en main. mais où on va être sur des bases de données relationnelles, et du coup chaque tableau, chaque colonne ne sera pas un simple, ne sera pas que du chiffre, sera moins rigide et mieux pensé qu'un Excel, ce ne sont pas les mêmes finalités. Mais vous voyez qu'à travers ces trois exemples, on a trois visions différentes d'une suite bureautique, et qui ont évolué forcément à travers les technologies, et les phases d'évolution, et la prise en main aussi des gens. Peut-être qu'un Notion à l'époque de Microsoft Office n'aurait pas du tout fonctionné parce qu'il aurait été trop avant-gardiste. Il y a aussi toute une logique quand même de répondre à un besoin, mais d'une manière que les gens sont aussi en mesure de s'en saisir et de le prendre en main. D'ailleurs, les premières versions de Notion n'étaient pas bonnes en termes d'expérience utilisateur et ont dû être repensées. Donc généralement, quand vous avez un programme aussi dans les mains, ne vous dites jamais qu'il est arrivé comme ça, tel quel déjà prêt. Il est passé par plein de phases en amont. Au début, c'était probablement une version brouillon, un peu éclatée, que personne ne comprend, avant qu'on identifie ce qui va et ce qui ne va pas dedans, pour que ça arrive à quelque chose de propre et d'agréable à utiliser. Et voilà. Tout ça pour en revenir aux besoins, c'est que ça part justement de quelque chose qui est concret, et qu'on va pouvoir, comme disait Lulu, le peaufiner et mieux l'interpréter, le comprendre, à travers des discussions, les fameuses discussions qu'on appelle avec les métiers. Donc là, ça peut prendre des formes d'atelier métier, d'entretien métier. Le but, c'est de mettre des gens dans la même pièce ou d'interagir et de discuter directement avec des responsables qui font ce boulot au quotidien et qui sont les premiers concernés.
Lulu
Ça ou l'étude de marché aussi ? Si le produit est destiné pas forcément à une entreprise, mais plus à des utilisateurs lambda, on peut... Oui, mais est-ce que... Je ne sais pas si on les appellera des métiers, les gens, si c'est par exemple du SaaS.
Manu
Oui, ça dépend, effectivement. Si tu t'adresses à du particulier ou à de l'entreprise, mais en tout cas, voilà. Il faut discuter avec des gens. C'est ça. À un moment ou à un autre, il faut parler avec des gens qui vont avoir besoin, enfin, celles et ceux pour qui vous voulez créer le produit et répondre aux besoins. Il n'y a pas de meilleur moyen de comprendre leurs problèmes qu'en parlant avec eux. Ou après, il y a des phases d'observation aussi qui peuvent être faites. Donc, typiquement... dans des contextes d'entreprise, d'aller voir un peu comment les gens bossent au quotidien et de se rendre compte qu'ils font du Excel, qu'ils font de tels outils bricolés. Et c'est là qu'on va voir encore davantage les petites failles et comment ils y auront répondu dans l'immédiat et se dire que c'est des pistes de réflexion, de se dire, en fait, il a pensé à sa solution de telle manière, ce qui pourrait sembler complètement pas efficient quand on le voit de l'extérieur, mais du coup, qui va donner des indices sur la manière dont les gens bossent et pensent leur solution. Il va y avoir d'autres approches aussi. Donc, tu l'as dit, la partie études de marché, études de l'existant. Il y a déjà plein de concurrents, il y a plein d'outils. On va mettre les mains dedans. Et d'ailleurs, ça que ce soit dans toutes les logiques produits, et quand on pense des nouvelles fonctionnalités, quand on va améliorer un logiciel, ou le concevoir de toutes pièces aussi, on va forcément mettre les mains dans les logiciels qui se rapprochent le plus sur le marché et voir un peu ce qu'ils proposent et ce qu'ils ne proposent pas. En fait, c'est aussi un des points de compréhension du besoin, de se dire que la plupart des acteurs ont mis en avant tel sujet et telle manière d'y répondre, parce qu'en fait, ils s'adressent, je viens de bêtiser, tous et toutes aux PME et aux grosses boîtes. Mais en fait, ce même problème existe chez les TPE, et personne ne l'a traité aujourd'hui, parce que c'était peut-être trop galère à faire, ou trop compliqué, ou machin, alors qu'il y a un autre angle, alors qu'il y a une autre manière d'envisager le problème.
Lulu
Et ce n'est pas parce qu'on a... un problème, nous, que ça veut dire qu'il faut forcément faire un produit, il faut le confronter, c'est pas forcément une phase agréable parce qu'on va se prendre des retours, ça va potentiellement modifier l'idée qu'on pouvait avoir de notre solution parce qu'on a souvent tendance à penser directement aux solutions de comment notre application, elle, pourra faire, machin, et que au final, des fois, la solution, elle pourrait être beaucoup plus simple, moins waouh, enfin... Et juste d'aller confronter et de se rendre compte que peut-être il y a déjà des solutions qui existent et on peut être tout seul à avoir ce problème. Alors c'est assez rare, mais ça ne vaut pas le coup de sortir tout de suite le développement, de partir à l'étape d'après. C'est presque l'étape-là qui est... la plus importante, alors les autres le sont aussi, mais toutes les autres, aussi bien qu'elles seront exécutées, si la base n'est pas solide, parce que si on définit mal un besoin et qu'on se rend compte finalement qu'il y a telle fonctionnalité, enfin, pas fonctionnelle, parce qu'il y a aussi le côté fonctionnel, non fonctionnel qu'il faut séparer, mais si on se rend compte que finalement il faut qu'on ajuste quelque chose, c'est beaucoup plus facile au stade de découverte et de... pour définir le besoin et les problèmes, qu'au moment où tout est développé, il y a des dépendances, il faut changer du code et potentiellement des choses qui vont coûter très cher. C'est un peu comme passer par un architecte avant de se lancer dans une construction, une grosse rénovation. Il va faire des plans. Peut-être que les plans ne seront pas suivis au millimètre près, mais ça donne déjà une idée de l'ordre d'exécution, de se projeter aussi. Et que si on se dit, ah bah tiens, finalement, je vois... plus ma cloison comme ça, la cloison, on va juste la déplacer un peu dans un logiciel où on gomme et puis on refait notre cloison. Alors qu'une fois que c'est monté et qu'on est là et que tout est fait, on se dit, c'est vrai que ça aurait été bien un peu différemment. C'est pareil dans un logiciel, il ne suffira pas non plus de juste prompter et dire, finalement, mon interface, je la verrai complètement différente qui va faire aussi modifier complètement le back-end. Voilà, c'est important.
Manu
Oui, mais j'aime bien la métaphore, parce qu'effectivement, c'est plus facile de pincer les murs à l'avance que de les monter une fois, se rendre compte que la moitié ne va pas, les casser et les refaire différemment.
Lulu
Surtout quand tu vois toutes les couches qui se rajoutent par-dessus, ou peut-être elle, j'ai fait ta trichoterie, ou c'est comme par exemple de se dire, tiens, dans cette pièce, je veux mes prises ici, Si on ne se dit pas où est-ce qu'on va penser nos meubles, alors ça demande de se projeter pas mal et ce n'est pas ce qu'il y a de plus confortable, ça demande pas mal d'énergie. Mais il faut savoir qu'il y aura toujours des choses qui vont se passer pas comme prévu. Donc tout ce qu'on peut prévoir au départ, ça sera de l'argent et du temps gagné pour après.
Manu
Effectivement. Et à garder en tête qu'en fait, plus tôt vous allez, plus vous avez d'infos au départ, plus les étapes d'après vont être fluides et pertinentes, plus vous bâclez ou vous... Prenez pas le temps de réfléchir vraiment aux besoins initiaux et comment on peut y répondre de la manière la plus simple possible. Comme disait Lulu, plus derrière, vous risquez d'avoir un espèce d'effet qui va se décupler en termes d'efforts, en termes de temps, en termes d'impact et où chaque chose à reprendre sera beaucoup plus galère à faire derrière.
Lulu
En soi, oui, une prise, on peut en rajouter un endroit, mais ça veut dire refaire une saignée potentiellement dans le mur qui est tout propre, qui est tout beau avec... le placo qui est déjà mis, la plomberie, mince, on s'en a saigné, on tape dans un tuyau. Autant imaginer, essayer d'imaginer de se projeter dès le départ, quitte à passer un peu plus de temps. C'est vrai que les personnes techniques ou même les clients ont vite envie de voir quelque chose et d'attaquer le développement, parce que c'est là que le projet commence vraiment. Et ça peut paraître un peu long, cette phase de... Demandez de comprendre les process, l'entreprise, parce qu'aussi, il y a un moment où il faudra arrêter et de se dire, OK, notre produit devra ressembler à ça. Et de bien le penser pour que quand même, s'il y a des choses qui doivent se rajouter, ça puisse se rajouter après dans une deuxième version. Mais on ne peut pas non plus juste rajouter au fil de l'eau. Il faut quand même imaginer un produit fini et s'y tenir. Là,
Manu
on est en train de glisser déjà dans la phase d'après, qui est l'étape de conception. On va commencer à baliser un petit peu effectivement cette notion de version et des choses qu'on vous a expliquées la dernière fois. Juste pour terminer sur cette étape recueil de besoins, justement, tu l'as évoqué rapidement, qu'on doit distinguer justement ce qui est du fonctionnel du non fonctionnel. Est-ce que tu peux nous clarifier ça un peu ?
Lulu
Le fonctionnel, par définition, c'est vraiment ce que le système va faire. Et le non fonctionnel, c'est comment il va le faire. Et ça, on en avait parlé justement dans l'épisode précédent. Toute la phase de PRD et les user stories, ça va vraiment être dans le fonctionnel. Et le non fonctionnel arrive seulement après.
Manu
Ouais. En fait, disons, quand on va réfléchir à nos besoins, et prendre les infos et discuter avec les gens, etc., on va d'abord se concentrer sur le fonctionnel. Donc en gros, qu'est-ce que... le logiciel doit faire pour répondre à leurs besoins et le non fonctionnel ce sera l'envers du décor et la partie un peu plus technique un peu plus galère de se dire ok Ils ont besoin d'un logiciel qui leur permet de cliquer et de faire telle et telle action. Mais en fait, est-ce qu'ils en ont besoin sur leur ordinateur en ligne, sur leur tablette, sur leur téléphone ? Est-ce qu'ils peuvent se passer du réseau ou pas ? Des points comme ça qui vont déterminer après la partie technique qui va être un peu tous les à côté, sur l'architecture, sur les langages, sur l'infrastructure, enfin un certain nombre de choses. Là où le fonctionnel, c'est vraiment dans le quotidien de la personne. qu'est-ce qui doit se faire avoir à disposition pour que ça marche et que ça...
Lulu
Qu'est-ce qu'il y a avant et qu'est-ce qu'il y a après l'utilisation, mais sans passer par le comment on va faire pour transformer l'avant et l'après.
Manu
C'est ça. Et donc, tu l'as dit rapidement, l'étape d'après, ça va être la partie conception. Et là-dessus, n'hésitez pas à revenir, on vous renvoie vers notre épisode précédent et on va passer un peu rapidement sur ces points-là. Mais c'est là en fait où on va s'attaquer au fameux PRD, au User Story. Donc le PRD en gros c'est le cahier des charges fonctionnel. Donc si vous avez bien fait votre affornement et pris toutes les infos, vous allez pouvoir le traduire en une espèce de cahier des charges qui va décrire les parcours utilisateurs qui sont souhaités, qui va permettre aussi de décrire justement ce qu'on appelle les User Story. Donc de dire chaque profil dans mon application, que ce soit un administrateur, que ce soit un utilisateur, que ce soit un... super manager, etc., chaque niveau de profil doit pouvoir faire des choses différentes dans le programme et on va lister en fait chaque chose qu'il doit faire dans le programme. C'est-à-dire, il faut qu'il puisse valider un formulaire, il faut qu'il puisse rajouter une nouvelle entrée de tel élément, il faut qu'il puisse imprimer tel document, il faut qu'il puisse télécharger telle chose, il faut qu'il puisse avoir telle information à disposition, et ainsi de suite. Encore une fois, on parle un petit peu plus de ces deux points dans l'épisode précédent, on vous y renvoie. Là, l'idée, c'est que vous ayez vraiment juste la logique de se dire à chaque fois, on passe par ces points-là. Et c'est ça qui va commencer à nous permettre de déterminer les différents briques, de déterminer les différents éléments techniques dont on va avoir besoin pour aller plus loin et avant de se lancer vraiment dans le développement.
Lulu
C'est ça, c'est vraiment, on va traduire les besoins en architecture. Enfin voilà, quelles briques ? comment ces briques vont communiquer entre elles, où vont être les données. C'est là où il y a un concept de cohésion forte-couplage faible, où chaque brique va faire une seule chose, et elle va dépendre le moins possible des autres, mais après il va y avoir ce travail de les mettre ensemble pour qu'elles fonctionnent bien. En fait, la partie... Plage fort, par exemple, pour donner une image, c'est comme si tout est un peu soudé et après, une fois que c'est mis en place et qu'on veut enlever un élément ou modifier un élément, ça va forcément impacter ce qu'il y a autour. Mais le coup plage faible, ça va être plutôt on va se mettre un rôle par brique et ça sera plus simple de les faire. C'est un peu comme ça où ça fonctionne dans certaines boîtes en feature. Et après, le but, c'est de faire de l'assemblage.
Manu
Oui, je suis en train de réfléchir à justement si j'avais... parce que ça me fait toujours penser aux bases de données, aux bases de données relationnelles.
Lulu
Oui.
Manu
Mais j'essaie de retrouver un exemple qui soit facile à vous donner. Mais en fait, l'idée de ce système de briques, c'est comme dans un système d'informations, justement une base de données où vous allez ranger les informations. C'est de se dire que chaque élément, dans la mesure du possible, doit être indépendant, quitte à ce qu'il soit relié les uns les autres. mais pour que quand vous allez toucher un point, vous n'ayez pas à toucher à tout le reste.
Lulu
Surtout si cet élément est amené à bouger, ou qu'on va devoir y tirer dessus. Si on sait dès le départ qu'il ne va pas rester fixe tel quel, il faut autant que possible faire en sorte qu'on puisse le modifier après coup, sans impacter toutes les autres fonctionnalités.
Manu
Oui, et je donne un exemple un peu cassé avec l'adresse. Mais ici on peut reprendre l'adresse. En fait, par exemple, votre adresse, ce n'est pas un seul bloc. Ça va être plusieurs éléments et si vous allez justement sur n'importe quel formulaire de l'administration et que vous avez besoin de remplir des papiers ou de vous inscrire je ne sais où, à chaque fois vous allez voir que vous allez dissocier votre code postal de la ville, vous allez dissocier le numéro de votre rue, de votre avenue, le type de rue ou d'avenue. Vous allez voir ensuite l'intitulé de votre avenue. Si vous êtes sur un immeuble, vous allez voir aussi des étages. Vous avez vu qu'en fait, toutes ces informations sont à chaque fois séparées. Puisque ça va permettre de mettre à jour les différentes informations et les différentes briques qu'il y a derrière de manière indépendante sans avoir à... changer toute votre adresse à chaque fois. Désolé, je ne sais pas si l'exemple est très parlant. Enfin, visuellement aussi, vous voyez un peu le découpage. Et en fait, il faut vous dire que dans une base de données, ça va être le même principe. Et après, quand vous allez mettre en place des fonctionnalités dans un logiciel, ça va être un petit peu la même logique. C'est-à-dire qu'on va essayer d'avoir le plus de... Comment dire ? On va essayer de ne pas réinventer la roue à chaque fois.
Lulu
Ah, nid de l'huile.
Manu
Globalement, en fait, c'est ça. C'est de se dire qu'aujourd'hui, par exemple, j'arrive sur une page web où vous avez différents boutons, vous avez plusieurs, je ne sais pas, vous avez deux tableaux, mettons, vous avez plusieurs informations au même endroit. Tout ça, si c'est un seul, une seule entité, un seul bloc, un seul élément, et que vous avez besoin de changer juste la couleur de votre bouton, en fait, potentiellement, la couleur de votre bouton est par exemple le lien qui va derrière. si tout ça est un seul élément vous avez besoin de retoucher l'entièreté et donc de ça a plein d'applications techniques derrière qui rendent le truc galère alors que si le bouton il est isolé et peut-être même encore mieux d'ailleurs on va prendre le bouton mais d'une manière différente vous avez un bouton validé qui est partout dans votre application votre site internet si vous avez un bouton justement qui est indépendant et qui est mutualisé vous allez réutiliser un peu partout si vous changez la couleur à un endroit ça va la changer partout si votre bouton il est intégré dans d'autres blocs, dans d'autres éléments, et qu'il n'est pas indépendant, vous allez devoir aller sur chaque page de votre site Internet pour changer la couleur de votre bouton. Et c'est un peu tout comme ça, globalement.
Lulu
Là, c'est bien visuel, mais c'est là où on dit qu'il ne faut pas le coder en dur, et qu'il y a un peu le côté où on va mettre en place des variables qui permettent de changer tout d'un coup. Par exemple, une charte graphique qui est peut-être amenée à bouger. C'est bien de la dissocier de tout le reste et de se dire, « Bon, bah tiens, telle couleur, si je la modifie ici, ça va la modifier partout dans mon appli, dans mon site. » Parce que sinon, aller remodifier tout à la main, c'est impossible. Ça, c'est aussi quelque chose qu'il faut garder en tête et à laquelle il faut faire attention. Parce que ça peut coûter cher. Sur le coup, on se dit, « Ah ouais, mon bouton, il est bien de cette couleur-là, c'est bien, la police, elle est bien. » Et arrivé à la fin, on a plein, plein de boutons et on se dit, « Ah, mais c'est vrai qu'un tout petit peu plus gros, ça serait pratique. » Oui, s'il faut aller le faire 20 fois ou 30 fois sur chaque bout d'eau.
Manu
Oui, par exemple, pour reprendre un exemple que nous, on a eu sur notre portail à nous en interne, c'est qu'on a plusieurs endroits dans notre portail qui nous permettent de rédiger du texte. Puisqu'il y a un endroit où on va préparer la trame de l'épisode, on va écrire dedans. Il y a des endroits où on va rédiger le texte qui va servir à la diffusion de ce podcast et qui sera présent sur un groupe. qu'on va renvoyer sur Ausha et qui arrivera dans votre Spotify, dans votre YouTube, etc. On a un autre endroit où on va pouvoir préparer le texte, on va le mettre sur LinkedIn, et ainsi de suite. On a plein d'endroits comme ça. Et là, l'idée, plutôt que d'avoir là aussi plein de briques du coup indépendantes, mais chacun sur leur interface, on va dire ça comme ça, on a pensé la mutualisation, et donc j'ai un éditeur qui va être réutilisé un petit peu partout et qui va partager des fonctionnalités. Et dans des cas particuliers, lui soit il va être il y aura une déclinaison différente de lui, soit ce sera complètement un autre éditeur, si jamais vraiment on est sur un cas très spécifique et très particulier. Mais on va toujours penser, voilà, tout ce qu'on fait dans une application, dans les interfaces, on va le penser en système de briques, avec qu'est-ce qui est commun, qu'est-ce qui est réutilisable, qu'est-ce qui vaut mieux dès maintenant, penser pour être réutilisé un petit peu partout dans l'application, plutôt que de faire que des petits morceaux et de devoir repasser partout à chaque fois qu'il y a une modif, et du coup de faire des bêtises.
Lulu
Parce que là, c'est vrai qu'on est sur du visuel, mais si on a une application et qu'on développe, par exemple, une fonction qui va faire quelque chose, on ne va pas avoir plein de fois cette fonction différente. Parce que même après, en termes de performance, ce n'est pas ce qu'il y a de plus efficient non plus. Et là, ça peut se ressentir au-delà juste du visuel.
Manu
Oui, c'est que concrètement, si vous avez 10 pages dans votre outil de tous les jours et que vous avez 10 fois les mêmes choses, en fait, ça va ramer vachement plus que si vous l'aviez une fois. et que c'était la même chose qui était réutilisée un petit peu partout.
Lulu
Et c'est plus simple de le penser dès le départ que de se dire après coup, comment est-ce que j'optimise mon application ?
Manu
Et là où le raccourci qui peut être fait souvent, enfin souvent, pas souvent, mais en tout cas selon les philosophies, selon les cas, ça peut être un mauvais réflexe, on va dire, de se dire bon, j'ai envie de sortir vite une nouvelle chose, une nouvelle fonctionnalité, de vouloir aller au plus court. Et souvent, le chemin le plus court, c'est d'aller pas penser en termes de mutier. de mutualisation et de réutilisation. et de faire juste la chose la plus simple possible. Mais du coup, ça a des implications derrière, parce qu'une fois qu'on va commencer à empiler des choses là-dessus, c'est d'autant plus dur. On en revient à l'exemple de tout à l'heure avec le coup de la maison. C'est que typiquement, si vous faites une canalisation un petit peu à l'arrache, et que le reste suit, vous allez commencer à mettre votre sol par-dessus. du coup vos meubles, votre tapis, vos machins et qu'après vous vous rendez compte qu'en fait il faut refaire toutes les canalisations parce que vous en avez pensé qu'une et qu'il en fallait trois, vous allez devoir littéralement tout virer et tout reprendre pour ensuite aller faire les différents chemins derrière. Alors ça n'impliquera pas de tout recasser mais en tout cas de tout bouger.
Lulu
Ou de faire du bricolage et de ne pas faire aussi bien que si ça avait été pensé dès le départ. Et aussi optimiser, voilà. Ça demande de prendre en compte l'existant, de ne pas tout enlever. Alors dans tous les cas, Enfin voilà. On ne peut pas tout prévoir, mais il faut quand même se poser. Là, juste pour passer aussi un peu à la partie d'après, parce qu'au final, on parle, on parle. Là, je pense que tu seras peut-être plus apte à en parler, tout ce qui est développement et versionnage. Parce que c'est vrai que maintenant, avec le développement assisté par IA, le vibe coding, on parle beaucoup de Git et GitHub sans forcément savoir ce que ça implique. comment ça fonctionne et pourquoi c'est utile aussi.
Manu
Oui. Alors, on va reprendre dans l'ordre. Donc, jusque-là, d'accord, on a été parler avec des gens, on a trouvé un problème, on a identifié du coup qu'est-ce qui pourrait y répondre. À partir de là, on s'est posé pour réfléchir à de quoi on a besoin dans notre application pour répondre à ce problème et on a pensé un petit peu les interfaces et tout ça. Donc normalement arrivé à ce moment là, on a un petit peu tout sur papier ou sur numérique, on a une maquette, on a plein de cahiers de décharge, on a plein d'informations. On voit vraiment ce qu'on veut faire et on voit vraiment les interfaces, donc grosso modo ce qu'on veut vous mettre dans les mains pour que vous puissiez vous en servir. Maintenant, il va falloir s'attaquer au développement. Mais le développement, je vais prendre le cas d'une équipe avec plusieurs personnes pour que ce soit un peu plus prudent. si chacun... doit bosser. En mettant que vous avez trois développeurs et développeuses, ces trois personnes vont devoir travailler. Elles ne vont pas pouvoir bosser sur le même sujet en même temps. Puisque techniquement, en fait, ça ne va pas le faire.
Lulu
L'intercom de l'analogie d'un document partagé en ligne où on veut travailler tous sur le même paragraphe en écrivant, effaçant, c'est juste impossible.
Manu
Oui, voilà, exactement. Ça ne marchera pas. Il faut se séparer, se dire dans ce document, On a trois parties, chacun va bosser sur une partie. Et voilà, ça va être le postulat de départ. Mais pour que ça puisse fonctionner, et que chacun puisse bosser de son côté sur sa partie, et qu'on puisse après tout réunifier en un seul document, il faut mettre en place un protocole, et on va mettre en place ce qu'on appelle un protocole qui permet de faire du versionnage, et un des plus utilisés aujourd'hui, c'est Git. Alors je ne vais pas rentrer dans l'historique maintenant, déjà parce que je ne l'ai plus trop en tête. mais en gros ce protocole va être très utilisé notamment par GitHub et GitLab qui sont deux des plus gros acteurs dont vous avez pu entendre parler, ou en tout cas voir le nom. Mais il y en a d'autres, il y a d'autres systèmes de versionning, certains qui s'appuient aussi sur Git mais qui ont une façon de le gérer différemment, d'autres qui n'utilisent pas Git et qui font encore autre chose. Mais dans tous les cas, le principe de Git c'est de se dire on a notre document final qu'on va appeler le main. qui va être vraiment notre... C'est la page commune, c'est la page que la personne va voir à la fin, que l'utilisateur va voir à la fin. Et c'est là que tout doit arriver. Mais on ne peut pas mettre à disposition et en lecture le brouillon. Parce que pendant que les gens bossent sur chaque partie, ce ne sont que des brouillons de chaque partie. Donc sur cette page, on va attendre que chacun ait terminé. Et pour faire ça, le protocole va permettre à chacun d'aller travailler sur ce qu'on appelle les branches. des branches. Vous n'êtes pas obligé d'utiliser des branches, mais quand vous êtes une équipe, normalement, c'est ce qui se fait. C'est que chacun travaille sur une branche. Et en fait, sur chaque branche, donc globalement, dites-vous qu'en fait, le document principal, pour l'instant, il a juste une introduction. Vous avez fait trois copies de ce document. Chaque personne travaille sur une partie différente de ce document. Et au fur et à mesure que chaque personne va avoir une partie ou un paragraphe qui est terminé, on va dire un paragraphe, c'est comme s'il appuyait sur enregistrer. Et à partir de là, ça va faire ce qu'on appelle un commit. Donc en gros, il va valider cette section-là, enfin voilà, ce paragraphe, il va le valider, il va dire OK. ça c'est bon, je considère qu'il est prêt, et même si j'ai besoin d'aller rajouter des choses plus tard au travail, mais en tout cas cette partie elle est enregistrée, elle est disponible, elle est visible sur ma branche, et du coup même les collègues s'ils viennent regarder ma partie, ils ne verront pas le deuxième paragraphe sur lequel je suis encore en train de bosser, et par contre le premier ils vont le voir. Et en fait chacun fait ça de son côté, et à partir de là, une fois que chacun fait tous ses commits, donc tous ses paragraphes et que les trois parties sont à peu près prêtes, Et voilà, ça peut être à des rythmes différents en fonction des personnes. Et puis de la charge aussi, parce que ça fait partie aussi des logiques de développement. C'est de se dire qu'en fait, tout le monde n'a pas forcément la charge, le même effort de travail sur une partie. Il y en a des plus courtes, il y en a des plus longues. Et chacun peut avoir ses spécialités aussi. Et voilà, qui vont avoir du coup des choses qui peuvent bloquer d'autres gens. Par exemple, la partie 3, peut-être que la personne va pouvoir faire les deux premiers paragraphes, mais pour le troisième, elle ne pourra pas le rédiger tant qu'elle n'aura pas les parties 1 et 2 qui sont terminées. Il peut y avoir comme ça des systèmes de dépendance. Dans l'idée, on va répartir en parallèle le travail de chacun. Une fois que les trois parties sont prêtes, ils vont faire ce qu'on appelle des pull requests. Le mot fait très peur, mais le concept est très simple. C'est de se dire, j'ai fini ma partie, je l'envoie à relire et à valider par les copains. Et en fait, cette partie-là n'arrivera pas dans le document principal tant que... les collègues devs n'auront pas relu. Ils vont venir, ils vont regarder. OK, en fait, tu as écrit ce paragraphe. OK, ça, c'est bien. Ah, là, il y a un petit souci. Du coup, on va le pointer en disant, en fait, cette partie-là, il faut un petit peu la remanier parce qu'elle ne me semble pas bonne. Il y a un truc qui ne va pas. Donc là, la personne qui a rédigé justement la partie, elle va venir, elle va faire la petite modif. Hop, elle va resoumettre à validation. Et donc là, on va du coup... Les collègues vont dire, ok, très bien, cette pull request, cette PR, si jamais on vous entendait parler de PR, c'est ça en fait. Là, je parle de paragraphe, mais dites-vous que c'est du code. Depuis tout à l'heure, je vulgarise comme ça avec l'exemple du document, mais à la place du texte, dites-vous que c'est du code. Et donc, une fois que la PR est prête, elle va être validée et elle va partir, justement, elle va fusionner avec la page principale, donc avec le main. Et ensuite, du coup, on va continuer comme ça. Chaque fois, les pull requests vont avoir plus ou moins de... Soit elles vont être validées directement, soit elles vont demander plusieurs allers-retours, plusieurs correctifs, mais ça va être cette logique-là. Et des fois, il peut y avoir aussi deux PR qui vont être en conflit. C'est-à-dire que, justement, chacun bossait sur une partie différente, partie 2 et partie 3, mais en fait, il y avait un paragraphe qui était commun entre les deux et que les deux personnes n'ont pas la même version du paragraphe. Il y a une phrase ou deux qui diffèrent. Et bien là, au moment de fusionner, il va falloir choisir avant de fusionner quelle version du paragraphe on garde, et laquelle en fait est la plus récente, la plus à jour, et la plus logique par rapport à l'ensemble du document. Puisque en même temps, comme je disais, on travaille en parallèle, donc il peut y avoir d'autres gens qui ont avancé davantage sur d'autres bouts, et qu'on n'avait pas forcément conscience à ce moment-là, et donc voilà, on fait une relecture. D'où l'importance de ces phases qu'on appelle des phases de review, vraiment, du PR, donc de relire. le document et la partie de document. Une fois que tout est prêt, à chaque fois, on va fusionner, on envoie dans le document principal et les pages s'ajoutent. Évidemment, vous l'aurez compris, cette page principale, ce document principal, c'est votre code de l'application et ça se traduit pour vous en tant qu'utilisateur en une interface avec des choses à cliquer, avec des pages, avec plein de choses comme ça. Est-ce que sur cette partie-là, Lulu, tu veux que je clarifie d'autres points ? Je ne sais pas si tu avais d'autres points. Non,
Lulu
ça me semble... Ça me semble bien et ça montre d'autant plus l'intérêt d'utiliser ces techniques-là, même si on développe tout seul avec plusieurs agents. Parce que là, d'autant plus, on se rend compte que le code avec IA va produire du code où tout est plus ou moins dépendant. Ce n'est plus forcément séparé par section claire, surtout si on n'a pas bien défini en amont et qu'on envoie notre agent. coder sur une fonctionnalité mais on ne l'a pas forcément bien découpé donc ça va toucher à plusieurs endroits du code. Donc imaginez, vous avez plusieurs agents qui travaillent en même temps sur un projet qui est en local, ils vont peut-être essayer de modifier des choses au même moment, au même endroit, et là après ça peut tout casser, ou induire des doublons, enfin voilà. C'est pour ça que c'est important, même si on développe tout seul, d'utiliser d'utiliser et... Git, bon après même si c'est en local, on peut utiliser Git quand même, mais après GitHub permet aussi de... Enfin, c'est vrai qu'il y avait la distinction, moi avant je ne connaissais pas forcément la distinction Git-GitHub, pour moi c'était la même chose et Git c'était en mode... Juste le raccourci,
Manu
l'abréviation. Je vais juste effectivement clarifier un peu ce point-là. C'est que le protocole Git, à la base, il permet de travailler sur son propre ordinateur avec ce système de version, de se dire à chaque fois, je fais une nouvelle version. Je vous ai parlé là des fusions et tout, mais je n'ai même pas revenu sur le terme de version. Mais du coup, le fait d'avoir des commits et après votre pull request et ensuite de venir justement fusionner tout ça, ça vous permet d'avoir une nouvelle version. Vous n'êtes pas obligé de faire des pull requests pour quand même... versionnés petit à petit au fur et à mesure des changements. J'ai pris l'exemple du contexte entreprise où on est à plusieurs et d'où les fameuses PR. Et effectivement, ce que vous allez avoir comme du GitHub ou du GitLab permet en fait d'avoir ce code et ces versions de code et tous les changements qui partent sur un serveur cloud. Donc chez GitHub, c'est chez du Microsoft aujourd'hui. Et GitLab, je pense que c'est juste GitLab d'ailleurs, je crois qu'ils n'ont pas d'instance au-dessus. Mais l'avantage de ça, c'est que du coup, le code va être centralisé sur un espace commun sur Internet. Et donc, n'importe quel développeur ou développeuse va pouvoir bosser sur son ordi en local, faire toute sa partie jusqu'au bout. Et une fois que sa partie est prête, elle va pouvoir faire le point avec ce qui est disponible en ligne. Et elle va l'envoyer en ligne et justement soumettre à validation pour lecture, etc. Et c'est aussi des fois d'ailleurs comme ça qu'on se rend compte qu'il y a des conflits. Autre personne, en bossant sur son ordi, au moment où elle a envoyé le code, elle est plus avancée que moi sur un truc qui était commun, et ainsi de suite. Et sur la manière de bosser en solo avec des agents, il y a plein de manières de le faire, avec plus ou moins de pull requests, avec plus ou moins d'enregistrements, etc. Mais ce qu'il faut garder en tête, c'est que Git, du coup, enfin Git ou un autre protocole de versionning, est très important, parce que ça vous permet en fait... de sauvegarder petit à petit votre progression et ce qui a été fait côté code, ça donne aussi des points de restauration. Donc en fait, si vous avez un pépin et que vous vous rendez compte que vous avez fait quelque chose qui ne marche pas et qui casse votre application, vous pouvez revenir en arrière sur une version antérieure. Et voilà, ce qui est fondamental, que ce soit tout seul ou à plusieurs. Et l'autre intérêt aussi de bosser comme ça, justement avec des branches, avec des versions et tout, c'est de se dire qu'en fait, à tout moment, Quelqu'un peut arriver sur votre repository, donc en gros sur votre dossier avec tout votre code, et qui peut reprendre le travail. De se dire, demain, s'il y a un dev qui arrive, qui prend mon code, il va pouvoir savoir où j'en suis, il va avoir l'historique de tout ce que j'ai développé, s'il y a une fonctionnalité qui fonctionne bien ou pas bien, il va pouvoir remonter, du coup, voir non seulement le détail du code, mais aussi l'historique qui est associé, et être à même de comprendre d'où vient le problème. ou qu'est-ce qu'il pourrait faire pour l'améliorer ou comment on va rajouter une nouvelle fonctionnalité, etc.
Lulu
D'où l'intérêt de bien documenter, de bien commenter aussi son code. Alors, c'est sûr que quand on est avec de l'IA, on ne va pas forcément lire le code, mais je pense que même pour suivre un projet, ça peut être intéressant de juste voir comment c'est fait et que ce soit pour qu'un humain ou une IA reprenne derrière des noms de fonctions clairs qui disent exactement ce qu'elles font, ou bien découpés. aussi une fonction à tout faire et de bien commenter, de bien documenter. Parce que que ce soit une IA, vous dans six mois ou quelqu'un d'autre, vous serez content de retrouver les commentaires et il faut penser à ceux qui viennent après. Petite référence à Claire Obscur. J'ai réussi.
Manu
Alors, du coup, est-ce qu'on se lance sur la partie d'après ou est-ce qu'on s'en tient là pour aujourd'hui, Lulu ?
Lulu
Je me dis qu'on peut quand même attaquer les tests parce que tu vas peut-être en parler pas mal la semaine prochaine et ça serait bien de dire au moins les différents... Parce que c'est pareil, notre application, à la fin, on ne va pas se dire « Ah bah tiens, je vais la tester à la fin » . C'est vraiment quelque chose qu'il y a à mettre en place à chaque étape de développement aussi et de se demander aussi, même avant de commencer à développer, de définir ses tests. En partie, mais je pense que là, tu en parleras un petit peu mieux parce qu'il y a différents types de tests. On entend parler, tu avais parlé aussi de recettes la semaine dernière. Et après, il y a les tests de régression, tests unitaires. Ça aussi, c'est du vocabulaire qui peut paraître un peu barbare quand on n'est pas dedans.
Manu
Oui, effectivement. Ok, alors, parce qu'on a déjà fait un petit peu long sur les trois premières parties, donc là, on va essayer d'aller un peu plus vite sur les trois suivantes. mais que vous ayez le panel complet justement du cycle de développement dès aujourd'hui n'hésitez à nous faire basculer sur deux épisodes pour vous n'ayez pas à vous en mettre trop dans la tête d'un coup. Mais en même temps, je pense que ce serait un peu frustrant de s'arrêter aussi à la moitié. Donc, je rejoins Guillaume. Au pire,
Lulu
vous écouterez en deux fois.
Manu
Oui, c'est ça. Ce sera pareil. Et alors, les tests. Les tests, les tests. Effectivement, il va y avoir plusieurs choses. On ne pourrait pas en parler longuement parce que ce que vous avez sous le nom d'assurance qualité ou de QA dans les entreprises, en tout cas chez les éditeurs de logiciels, c'est les services des... volontaire ou désigné volontaire pour aller casser les produits et les logiciels et trouver toutes les failles et les remonter aux développeurs qui vont râler parce qu'ils ont des nouvelles failles et des nouveaux bugs à corriger mais qui est fondamental pour éviter que ces bugs arrivent dans les mains des gens à la fin. Donc la première chose ça va être effectivement de penser les tests dès le départ donc ça on en avait déjà aussi parlé dans l'épisode précédent c'est de se dire quand on écrit une user story et qu'on dit tel profil doit pouvoir faire telle chose dans l'application on va y associer des critères d'acceptation, donc de dire en fait, pour valider que cette fonction-là, donc quand il clique dans ce bouton, ça marche, en fait, c'est les critères qui vont dire qu'est-ce qui fait que ça marche ou pas. Et associé à ça, en fait, on va avoir justement un carnet de tests ou un cahier de tests ou un carnet de recettes, enfin bon, plusieurs appellations. Mais en fait, en face de chacune de ces user stories, on va mettre des tests pour se dire, pour que tout... Ce bouton, il doit, par exemple, permettre d'ajouter une ligne dans mon tableau. Mais du coup, il faut que je teste tous les cas possibles et impossibles, c'est où ça devient rigolo, les fameux cas limites, de se dire en utilisation normale, la personne va remplir ces deux champs, cliquer sur le bouton, ça rajoute une ligne. Et en fait, si dans ces deux champs, j'ai un champ nom, j'ai un champ prénom, à la place, si elle met des chiffres, qu'est-ce qu'il se passe ? Si elle met des caractères spéciaux, qu'est-ce qu'il se passe ? Si elle ne met rien, qu'est-ce qu'il se passe ? Si elle met un script,
Lulu
qu'est-ce qui se passe ?
Manu
Si elle met un script, qu'est-ce qui se passe ? Ou si elle met... Alors ça, c'est un des tests qui est assez rigolo, d'ailleurs, quand on les voit passer. Si on met un texte sans fin dedans avec 2000 caractères, qu'est-ce qui se passe ? Et voilà. Et ensuite, à partir de là, on en déduit les tests à faire et la perce. Pas faire tout à fait dans ce temps-là. À ce moment-là, vous avez déjà un scénario de test qui est associé à chaque... un ou plusieurs scénarios de test qui sont associés à chaque fonctionnalité, globalement.
Lulu
C'est vraiment plus large et ça ne va pas tester juste un petit bout. On est vraiment dans le... On teste une fonctionnalité, une user story. On va tester une fonction dans le code. Là, on est vraiment sur presque le plus haut niveau de test, je pense.
Manu
Oui, c'est ça. C'est-à-dire qu'en fait, on va avoir plusieurs niveaux de test. Il va y avoir les tests... unitaire donc ça ça va être vraiment purement au niveau du code de se dire ben voilà le développeuse a créé a développé ce bouton qui permet de valider d'ajouter la nouvelle ligne avec les noms prénoms elle va mettre en place un test unitaire au niveau du code pour dire ben en fait quand je clique ça fait exactement ça insère donc un ajout du nom prénom dans la ligne de ces deux champs voilà typiquement test unitaire il va être là
Lulu
C'est une brique, on teste vraiment juste une petite brique, indépendamment du reste.
Manu
C'est ça. On va avoir des tests d'intégration. Selon les cas, ils viennent à des moments un peu différents, mais qui vont être là un petit peu pour l'environnement. Je vais en reparler juste après de cette notion d'environnement. Et donc, ils vont être un peu plus sur la partie vraiment technique, globalement, mais technique, pas du code, mais tout ce qu'il y a autour. le fait que le programme est disponible, où est-ce qu'il est disponible, de quelle manière il est disponible, un petit peu plus ces choses-là. Et on va avoir les tests dits end-to-end, qui sont en fait les tests type utilisateur, c'est-à-dire vraiment les tests de ce qui se passe quand on navigue sa souris dans le logiciel, ou sur le téléphone par exemple, et qu'on clique directement sur les boutons, etc. On reproduit le comportement d'une... personnes utilisant vraiment l'application. Et ces trois tests-là, déjà, on va pouvoir les... Comment dire ? On va pouvoir les automatiser, déjà. Test unitaire, intégration, etc. Les tests end-to-end, en fait, quand on les automatise, c'est qu'on va littéralement avoir un programme qui reproduit des clics à l'écran et qui reproduit des actions utilisateurs. Donc ça, c'est assez marrant à voir quand vous le faites. Et voilà, d'ailleurs, si vous développez avec de l'IA et que vous faites du vibe-coding, ben... demandez enfin j'espère que vous faites des tests end to end et quand il s'est le cas justement amusez vous à regarder les fenêtres de tests pendant qu'il les fait pour voir justement ce ces interactions en temps réel et Il y a des programmes qui sont dédiés, etc. pour faire ça. Mais les familles de tests, en gros, ça va être là-dessus. Après, on va avoir des tests de non-régression. Donc les tests de non-régression, en fait, entre guillemets, il peut y avoir un peu tout ça dans le lot, mais le but, c'est de se dire, en gros, quel est notre panel de tests dans les différentes familles qui valident et vérifient que notre programme n'est pas cassé et qu'on a... pas cassé un bout du logiciel en ajoutant une nouvelle fonctionnalité, même si, a priori, la nouvelle fonctionnalité n'avait rien à voir. Parce que ça, c'est un des cas, justement, des effets de bord, c'est de se dire en fait, je sais pas, je rajoute une nouvelle page dans mon programme, cette nouvelle page elle permet de faire des... de rajouter des tableaux alors qu'avant j'en avais pas, mais en fait, quand elle rajoute des tableaux, elle utilise un bouton qui était utilisé à un autre endroit et qu'en fait, ce bouton, du coup, on l'a retouché sans se rendre compte qu'il était utilisé à un autre endroit et ça va casser à ce moment-là. Ça marchera bien sur la page avec le tableau, mais ça marchera plus sur l'autre page qui utilisait le même bouton. Voilà, les tests de non-régression, en fait, ils sont là pour empêcher ça, enfin, pour empêcher ça, pour se rendre compte de ça. Parce que là,
Lulu
en plus, on parle de boutons où c'est visible, mais ça peut être des choses qui s'accumulent sans qu'on s'en rende compte, jusqu'à un point où c'est pour ça que c'est vraiment important de le penser et de garder ça en tête et de se dire que c'est pas parce que je modifie une partie là, d'autant plus si c'est en développement assisté par IA ou... On peut avoir un peu de code spaghetti, où il y a tout qui s'entremêle. Se dire, non, mais ça va, visuellement, je ne modifie que quelque chose qui est là, mais derrière, au final, ça va aller toucher d'autres choses et on ne s'en rendra pas compte avant de peut-être modifier autre chose ailleurs aussi. Donc, ça peut être vraiment exponentiel.
Manu
Oui, et là, c'est vrai que je parle beaucoup de boutons et de choses. Pour que vous arriviez à avoir quelque chose en tête, parce que déjà qu'on est quand même très abstrait sur plein de sujets, concepts, parce que si vous n'avez jamais fait de développement, C'est normal, ça fait beaucoup de nouveautés, de nouvelles idées, de nouvelles choses à intégrer. Mais dans la réalité des faits, effectivement, la majorité des cas et des bugs viennent de choses qu'on ne voit pas de prime abord. Même s'il y a aussi des petits tests, il peut y avoir des petits bugs d'interface, il peut y avoir des caractères. Il y a des choses qui sont visuelles, mais les soucis et les bugs les plus embêtants, comme disait Lulu, on ne les voit pas.
Lulu
C'est ça, et aussi de se rendre compte à quel moment on a cassé. parce que si on se rend compte que... rapidement, ça peut être facile de corriger tout de suite, de revenir à une ancienne version, de refaire autrement. Mais si on s'en rend compte plusieurs jours, plusieurs semaines après, et ça c'est vrai qu'IA accélère énormément le développement, les pull requests, et au final c'est le lenteau nord, le goulot d'étranglement, il est au niveau de la revue de code maintenant, et avec tout ça qui arrive très très vite, s'il y a quelque chose qui... passe à la trappe, mais on va rajouter d'autres choses, d'autres fonctionnalités, ce qui fait qu'on ne pourra pas juste se dire « je reviens en arrière au moment où ça a pété » , parce qu'il y a d'autres choses qui sont rajoutées en même temps et c'est là qu'on se retrouve à faire des choses pas très propres en général.
Manu
Oui, c'est là qu'on se retrouve avec de la dette technique, notamment. En fait, la dette technique, sur les cas où vous pouvez, les plus criards, vous pouvez en avoir, ça va être justement quand, au début, vous aviez une fonctionnalité à faire. vous voulez rajouter une nouvelle chose et en fait vous voulez la rajouter le plus vite possible sans vous prendre la tête à vous dire, en fait, est-ce que pour la faire bien, ça prendrait vachement de temps, c'est vachement complexe et il faut anticiper plein de choses. Moi, je veux juste que les utilisateurs et les utilisatrices l'aient très vite dans les mains. Je la fais de la manière la plus printée et la plus express. Sauf que la manière dont elle est conçue, effectivement, ça va pour deux semaines et un cas défini. Mais en fait, dès qu'on va vouloir... rajouter des choses sur cette fonctionnalité, on va se rendre compte que non, ce n'est pas possible parce que ce n'est pas qu'elle est mal conçue, c'est qu'elle n'est pas pensée pour évoluer.
Lulu
Ça ne prend pas forcément beaucoup de temps de faire des tests à chaque étape. C'est aussi à penser et que ça peut vraiment sauver son application après.
Manu
Alors, oui, justement, c'est là où je voulais revenir. Là, déjà, il y a de la technique juste de... de ne pas avoir anticipé assez ou d'avoir voulu aller trop vite et de manière qui ne peut pas évoluer derrière. Et par-dessus ça, on va rajouter les problèmes et les bugs liés au manque de tests et au manque de tests de qualité qui ne vont pas permettre de se rendre compte que cette fonctionnalité qu'on a développée très vite, elle a des problèmes qui sont visibles dès maintenant et qu'on va retarder. Et parmi ça, il peut y avoir par exemple des soucis de performance. Typiquement, il peut y avoir des... Vous rajoutez une nouvelle page qui va vous permettre de rajouter, en plus de votre nom, prénom, vous allez pouvoir rajouter votre adresse. Mais en fait, toute cette partie-là, elle est très mal faite. elle a été faite à l'arrache, elle n'est pas évolutive, et surtout elle consomme énormément de ressources. Et en fait, sur le moment, ça passe, parce que vous ne rajoutez que ça, mais vous allez vouloir rajouter une suite au formulaire pour aller prendre des informations complémentaires, et en fait, chaque fois que vous rajoutez des blocs sur votre formulaire, vous vous rendez compte que ça devient très très lent, et que toute la page ram. Et en fait, le problème va venir d'un des tout premiers composants, votre adresse. qui, rien que le fait qu'elle tourne sur la page, va consommer vachement de ressources de votre navigateur Chrome et va faire des ralentissements. Mais dès que vous allez faire d'autres choses supplémentaires, rajouter des composants, ça va rendre tout ça exponentiel. Chaque composant va rajouter le même ralentissement et à la fin, vous allez retrouver, quand vous cliquez, qu'il va devoir attendre plusieurs secondes pour qu'il se passe quelque chose, par exemple. Ça, c'est un cas de technique classique de l'IA de la performance qui peut être décelé notamment à travers des tests automatisés. Parce qu'en fait, dans les tests automatisés ou pas automatisés d'ailleurs, puisque c'est là, on va se rendre compte qu'il y a un problème. Si quand on clique sur le bouton, ce n'est pas immédiat et instantané et que ça prend 10 secondes, c'est qu'il y a quelque chose qui ne va pas quelque part. Et donc dans la QA, dans les services d'assurance qualité, comme ça, ils vont être en mesure de faire les deux, la partie test automatisé, mais aussi la partie test vraiment humaine, de se dire, OK, la machine, j'ai pu mettre en place un certain nombre de trucs pour que ça tourne tout seul. Parce qu'en fait, on invite des centaines de tests. Et donc, à chaque fonctionnalité, on ne peut pas faire des centaines de tests à la main. Mais à côté de ça, il y a besoin d'avoir ce regard humain pour se dire, attention, parce qu'en fait, ce truc-là, je n'ai pas pensé qu'on pouvait le prendre de telle ou de telle manière. Ou alors, le test que j'ai mis en place, il est bien, mais en fait, il ne dira pas si, justement, quand on va rajouter la prochaine fonctionnalité qui est prévue avec l'équipe, ça risque de poser souci. Et là, du coup, la personne... les personnes justement dans le service qualité apportent énormément de valeur côté produit et information. Au même titre que les utilisateurs finaux justement qui vont se servir de votre produit, mais à la qualité, en fait, ils vont avoir un regard tellement complet sur votre application qu'ils sont en mesure de vous montrer des choses, d'essoler des choses que vous ne pourriez pas faire différemment, que vous n'auriez pas pu voir différemment. On va dire ça comme ça. Et juste pour terminer justement sur ce sujet des tests, pour faire le lien avec notre...
Lulu
Là, tu as parlé des tests de non-régression, mais il y a aussi les tests de régression encore.
Manu
En fait, techniquement, c'est les tests de non-régression qui te font valider l'absence de régression. Ah, oui,
Lulu
d'accord. Parce que moi, j'avais tendance à entendre tests de régression, mais c'est tests de non-régression.
Manu
Du coup, je dis peut-être une bêtise sur le vrai terme officiel, mais j'ai toujours dit tests de non-régression, c'est un balut le principe étant que justement t'es toute ta suite de tests automatisés pour t'assurer comme on disait avant que quand t'as rajouté quelque chose, en tout cas t'as un palier de sécurité qui a tourné tout seul et voilà qui sont parmi les différents tests qu'on a déjà évoqué avant mais qui vont être aussi une sélection et il y a aussi le fameux smoke test,
Lulu
je ne sais pas si tu veux nous en parler de celui-là ça je l'ai découvert en préparant l'épisode c'est un à... Test, alors, il vient, c'est test de fumée, pour traduire littéralement, qui vient de l'électronique. En gros, c'est on va allumer et s'il y a de la fumée qui sort, on arrête et on considère que ce n'est pas bon. Voilà, donc en logiciel, on va lancer, on va faire des vérifications qui sont vitales. Et si ça ne passe pas, juste on ne va pas continuer à faire d'autres tests et investir du temps sur cette... partie-là du logiciel ou sur cette version du logiciel, parce que ça serait une perte de temps et de ressources.
Manu
Oui. Je suis en train de penser à mes usages, mais effectivement, c'est un test qui va à l'essentiel.
Lulu
Si ça, ça ne passe pas, on ne va pas aller vérifier si le bouton a la bonne couleur. Il y a d'autres choses à vérifier en amont. Et c'est vrai que quand tu parlais du formulaire aussi, On se dit, mais comment est-ce qu'on peut tester tout ? Parce qu'au final, c'est presque infini ce qui peut se passer. Et justement, on va essayer de choisir à chaque fois des valeurs ou des tests qui vont être représentatifs d'un intervalle ou qui vont être représentatifs de plusieurs tests qui vont permettre, par exemple, si on peut mettre des numéros, on va se dire, bon, on va tester, par exemple, je ne sais pas, 0, 1.
Manu
après on va tenter sans tester après aussi à chaque borne où on peut mettre, c'est souvent là où ça peut bugger si on met un nombre négatif si on met un chiffre à virgule et ça va pas être pertinent de tester tous les chiffres tous les nombres et juste prendre un test ou une valeur qui va représenter une famille de valeurs ouais et en fait il faut Ouais.
Lulu
à garder en tête, c'est qu'on ne peut pas tout tester. C'est juste pas possible. Et aucun logiciel n'a pas de bug. L'idée, c'est de ne pas avoir de bug visible, entre guillemets, et les traiter au fil de l'eau, justement de ne pas attendre qu'ils s'accumulent et qu'ils s'agglutinent, et surtout de traiter tous les problèmes majeurs le plus rapidement possible, mais sans pour autant délaisser les petits bugs mineurs, parce qu'en fait, il y a des soucis. Il peut y avoir des... petits pépins et des petits bugs moins importants mais qui sont pénibles dans l'utilisation quotidienne et qui sont aussi nécessaires de corriger petit à petit. Mais typiquement, il peut y avoir des cas où vous avez des bugs qui sont connus, qui ne sont pas traités volontairement parce qu'on sait que telle page ou tel composant, on va le faire évoluer. C'est déjà prévu qu'il évolue dans deux semaines, dans un mois. Et l'effort que ça prendrait de corriger le bug est beaucoup trop important. au vu du fait que de toute façon, cette partie-là va être refaite différemment et on ne va pas faire le boulot deux fois. Donc c'est ce qui fait aussi des fois que vous avez des bugs dans certains logiciels que vous allez voir, vous savez qu'ils sont là. Donc des fois, ils ne sont pas traités de suite parce qu'en fait, il n'y a plus prioritaire avant, il y a plus important et plus urgent et plus critique dans l'application. Et d'autres fois, mais en fait, ils sont connus, acceptés, tolérés parce que... la fonctionnalité ou le composant va être amené à changer. Et dans ces cas-là, soit il faut prendre son mal en patience, soit ne pas hésiter aussi à solliciter les services support, les équipes support qui ont généralement... C'est tout à l'aimant. Oui. Généralement, des astuces et des contournements à vous donner qui ne sont pas forcément idéaux, mais qui peuvent vous permettre de vous débloquer pour quand même arriver à vos fins sans avoir à attendre justement que la fonctionnalité soit terminée et que la nouvelle version soit disponible.
Manu
C'est vrai que c'est compliqué de trouver un peu cet équilibre entre la partie maintenance et régler des problèmes qui remontent, et la partie innovation où on veut rajouter des nouvelles fonctionnalités, parce que c'est sûr qu'il y a ce côté-là où le produit doit quand même vivre, l'application doit vivre, et on ne peut pas juste tout régler parce qu'il y a d'autres choses qui vont arriver, comme tu disais, au fil de l'eau. trouver un peu ce sweet spot entre on fait quand même évoluer l'appli, mais en même temps il ne faut pas qu'on casse tout et qu'on construit sur quelque chose qui est bancable. C'est pour ça qu'il y a certains moments aussi, on verra, où c'est mieux de recommencer. Ce n'est pas agréable, ça peut être compliqué, ça peut coûter, mais ça peut aussi coûter d'essayer de continuer à essayer de maintenir et de... pu avoir d'innovation et de se faire potentiellement dépasser par quelqu'un qui lance son nouveau logiciel.
Lulu
Oui, après, voilà, ça serait complètement vrai, mais ça va dépendre aussi de l'envergure de l'application et de l'objectif. Si vous faites du vape coding et que vous développez une application toute seule ou toute seule sur votre ordi, globalement, votre appli, une fois qu'elle est terminée et qu'elle répond à vos besoins, vous n'aurez peut-être jamais besoin de la faire évoluer pendant des années, et puis au bout d'un moment, juste... passer sur un autre produit ou faire une nouvelle version, enfin, peu importe. Et la même chose sur certains modules et certaines applis. Des fois, vous allez remplacer un logiciel entier par un nouveau qui est pensé différemment et qui correspond davantage à vos besoins. Ou au contraire, du coup, effectivement, des logiciels qui vont durer très longtemps vont de temps en temps changer des bouts de moteur et des bouts de l'application complète et ne changeront jamais tout d'un coup. Enfin, ça peut arriver en réalité, mais généralement c'est une nouvelle version qui va cohabiter avec une ancienne. Et le souci de cette Ausha, c'est que souvent, quand on a besoin de repartir de zéro avec un nouveau moteur et des technologies plus modernes, on ne peut pas répliquer à l'identique un logiciel qui existait depuis 20 ans et qui avait 20 ans de développement avec toutes ses fonctionnalités. Dans ces moments-là, on est obligé de trancher dans le vif, de sélectionner que les choses les plus critiques et les plus importantes dans la nouvelle version qui sera. fluide, rapide, modernisé, etc. tout très bien, mais qui perdra forcément un grand nombre de choses par rapport à l'ancienne. En partant du principe qu'on va vous mettre dans les mains la nouvelle version au top, et vous rajouter ce qui manque petit à petit. et que les bookings seront rajoutés petit à petit, ils seront mieux pensés, plus rapides et tout. Mais voilà, et ça c'est un des cas que j'ai déjà vu justement dans différentes boîtes où en fonction du client et de l'utilisateur final, ça va être « Ok, je préfère rester sur l'ancienne version, donc la nouvelle n'est pas assez mature, elle n'a pas ce dont j'ai besoin dans mon quotidien » ou au contraire, les fonctionnalités qu'il y a dans la nouvelle version, c'est juste ce dont j'ai besoin. Et c'est parfait, je peux basculer dessus. J'avais deux, trois broutilles que j'aimais bien raconter, mais je peux m'en passer pour le moment.
Manu
Parce que les langages aussi ont différentes versions. Et on ne peut pas juste, quand un nouveau, par exemple, un nouveau langage en Java sort, se dire, on fait la mise à jour et puis notre application, on passe au nouveau langage, à une nouvelle version de Java qui apporte des nouvelles fonctionnalités, des meilleures performances. Parce qu'il y a des choses qui ne marcheront plus. C'est un moment où on ne peut pas juste mettre à jour aussi facilement. Et c'est comme ça qu'on se retrouve. C'est ce qu'on appelle des refontes, quand on refait une partie. Et ça, c'est très connu, par exemple, dans le système bancaire, assurance. On va dire des boîtes qui ont des logiciels historiques. On va trouver peut-être encore des bouts de cobol aussi, qui est un très, très vieux langage.
Lulu
ça dans la banque c'est encore autre chose parce qu'ils sont un peu banque à l'aéroport etc ils ont des outils tellement critiques qui font durer et traîner des choses qui sont très technologiquement où il y a peu de gens qui sont encore en mesure de le réparer c'est
Manu
ça et puis des fois la refonte va prendre tellement de temps qu'elle sera déjà obsolète donc on se retrouve à faire des refontes de refontes et c'est sans fin donc voilà après ça c'est plus Aïe ! C'est à l'échelle vraiment d'une plus grosse boîte et tout ce qui est, on va dire, plus historique aussi. Automobile. Après, je pense que tu l'as peut-être rencontré dans des trucs plus récents, dans des contextes plus récents aussi.
Lulu
Oui, ce n'est pas forcément une taille de boîte, c'est vraiment plus une durée de vie du logiciel. Parce qu'en fait, tu peux avoir un petit programme qui est concerné, tout simplement, parce qu'il sera utilisé pendant 10 ans, pendant 5 ans, en plus. et pour lesquels, au bout d'un moment, il va y avoir certaines technologies ou certaines dépendances. On ne tirera pas là-dessus maintenant, mais dites-vous juste qu'un programme, quand vous le faites et quand vous le développez, vous ne développez jamais tout de zéro. Vous allez généralement vous appuyer sur des librairies, donc des bout de code qui ont été réalisés par d'autres, pour ne pas réinventer la roue à chaque fois. Mais la contrepartie de ça, c'est qu'il y a des briques qui peuvent ne plus être maintenues ou ne plus être compatibles avec des nouvelles versions. pour différentes raisons. Il peut y avoir des briques, justement, de dépendance qui se retrouvent avec des failles de sécurité dont on doit se passer pour aller sur quelque chose d'autre parce que les failles de sécurité ne peuvent pas être corrigées ou même si elles ont été corrigées, du coup, c'est un trop gros risque, etc. Enfin, il y a des considérations à prendre en compte. Il peut y avoir le fait de ne pas avoir pris de dépendance, d'avoir voulu coder soi-même une fonctionnalité et de se rendre compte qu'en fait, on n'était pas en mesure de bien la couvrir parce qu'elle était complexe techniquement. Il se retrouvait à utiliser des dépendances payantes ou des outils tiers qu'on va connecter aussi avec différents systèmes comme des API. Il y a plein de paramètres qui peuvent rentrer en jeu dans le fait de faire une refonte ou pas et que la refonte soit que sur des petits bouts, sur des grands bouts. On va prendre peut-être un exemple tout bon, mais aujourd'hui il y a beaucoup de logiciels et d'applications qui s'appuient sur Stripe qui fait toute la partie paiement. du coup ça devient une dépendance. Demain si Stripe pour une raison politique ou de sécurité ou comme ça, est plus compatible avec nos réglementations en France, du coup ça fait que toutes les boîtes qui s'habituent, elles l'ont dans l'offre, c'est qu'il faut soit qu'elles trouvent un autre équivalent à Stripe pour gérer toute la partie paiement de leur boîte, soit qu'elles développent eux-mêmes, et auquel cas c'est vraiment délicat parce que du coup dans les parties paiement il y a plein de choses qui sont vraiment... très sensible. Et puis même après, je pense qu'en termes réglementaires d'agrémenter tout, il y a des choses aussi à vendre. Mais voilà, pour citer un exemple de dépendance qui n'est pas une librairie pour le coup, qui est un outil tiers, mais qui est un outil tiers qu'on va intégrer et qui va être intégré dans plein plein de logiciels parce que c'est une brique tellement difficile à mettre en œuvre qu'on s'appuie sur de l'existant mais que cet existant a des contraintes.
Manu
C'est vrai que quand il y a eu aussi la mise en application du RGPD. Tout simplement, là, ça a demandé beaucoup de modifications, et là, c'est une réglementation qui évolue, et là, ça demande de mettre à jour, de rajouter des choses qui n'étaient pas prévues au départ dans un logiciel, et là, ça demande... Pas mal de boulot, je sais que ça a été compliqué dans pas mal de boîtes, la question RGPD. Oui,
Lulu
parce que le RGPD implique ne serait-ce que de pouvoir exporter tes données en tant qu'utilisateur. Donc en fait, il faut dans le logiciel en mettre en œuvre tout ce qu'il faut pour récupérer toutes tes données un peu partout et te permettre de les sortir de là, de les exporter, d'en avoir une copie complète. Et ils sont aussi censés te permettre de supprimer ou d'anonymiser en fonction des cas. peut être supprimé ou pas, parce qu'il y a des choses que techniquement tu ne vas pas pouvoir supprimer, mais du coup tu vas devoir basculer en anonymisation pour pas qu'on puisse remonter ta trace et en même temps que le logiciel continue à fonctionner. Quand elles sont reliées entre elles, si tu casses un bout, tu peux casser beaucoup de choses à côté, donc la suppression n'est pas si simple. Et après, en plus, tu dois rajouter d'autres contraintes, puisque notamment sur les parties RGPD, ça peut rentrer en contradiction avec d'autres règles de sécurité informatique en fonction de ton secteur et de la sensibilité, par exemple dans la santé ou d'autres domaines, la durée de rétention des données n'est pas la même. Et du coup, c'est toujours celle qui est en vigueur la plus critique, on va dire, qui va prendre le pas sur le RGPD et qui va le rendre caduque. Parce que si le RGPD te dit combien d'années il faut en standard pour la rétention des données, mais si d'un point de vue légal, on te dit que non, sur cet usage-là de santé, il faut garder les logs et la traçabilité pendant 10 ans. Pendant 10 ans, tu ne vas pas ni supprimer ni anonymiser parce que c'est une obligation légale d'avoir ces infos-là. Du coup, c'est des choses à prendre en compte, à mettre en œuvre d'un point de vue métier et d'un point de vue technique, ce qui peut amener plein de galères.
Manu
C'est là qu'on peut se rendre compte que c'est pertinent d'essayer au maximum de découper pour qu'on puisse presque y aller de manière chirurgicale pour modifier. Alors, ça ne sera pas possible de ne pas impacter et juste avoir des Legos qui sont fixés de manière, on va dire, simple, sans dépendance. Mais à un moment, il faudra quand même impacter d'autres fonctionnalités. Mais si c'est bien découpé, ça se passera mieux que si c'est un gros mélange où il faut se dire, si je modifie là, qu'est-ce que ça va casser autour ? mais en même temps, si je casse tout ça, est-ce que c'est... plus grave que de ne pas être en conformité.
Lulu
C'est là que typiquement, avoir une base de données bien structurée est fondamentale. Parce que tes éléments vont quand même être liés les uns les autres entre les différentes tables, entre les différentes entités d'information. Mais plus cette structure est efficiente, plus justement tu vas pouvoir identifier les infos qui vont bien, jongler d'une relation à une autre pour prendre ce que tu as besoin ou justement supprimer ou analyser ce que tu as besoin. sans tout casser. Et là où, comme on disait au tout début, comme le cas de l'adresse ou ce genre de choses, si c'est un seul tenant, un seul bloc d'informations, et dedans vous avez une info à enlever, mais qu'en fait, si vous enlevez cette info, vous êtes obligé d'enlever l'entièreté de l'adresse. Sinon, on va prendre l'exemple de l'adresse. Mais en fait, dans votre adresse, vous n'êtes plus à l'étage, vous êtes au rez-de-chaussée. Et si c'est un seul tenant, vous cassez toute l'adresse, vous supprimez toute l'adresse. Dans notre cas, vous allez juste mettre à jour une information de moi.
Manu
Ça ou par exemple si l'adresse c'est un seul bout, de se dire, je ne sais pas, demain il y a la réglementation qui change et les codes postaux changent. Ça peut être pratique que le code postal soit isolé tout seul et qu'on n'ait pas à remodifier tout et peut-être essayer de l'isoler alors que tout est imbriqué. Je pense que ça a été un peu le cas avec ce qui se passait avec le RGPD. penser aussi dedans comment est-ce que notre chemin de données, comment est-ce que c'est stocké, comment est-ce que les données sont séparées, comment est-ce que les rends accessibles...
Lulu
Et même d'ailleurs, aujourd'hui, quand tu fais un programme de zéro, si tu ne penses pas à ta conformité à RGPD au début, on ne va pas se mentir, c'est chiant.
Manu
Comme l'accessibilité, c'est à penser dès le début et pas à la fin.
Lulu
Oui, clairement. Allez, on embraye. On a bientôt fini, si vous êtes encore avec nous. on est presque alors on va terminer plus rapidement donc suite au test on a fait tout le panel et on va revenir au fameux concept de mise en production de quoi on parle ? Quand on développe alors on va avoir une structure classique, encore une fois selon les boîtes il peut y avoir plus ou moins d'environnement mais là le standard ça va être de se dire on a trois environnements, un qui est là pour le développement Donc c'est là où vos équipes de développement, vos développeurs et développeuses vont faire justement les différentes briques de code dont on a parlé tout à l'heure et leurs différentes versions, leurs PR, et balancer tout ça quelque part et ça arrivera généralement en dev. où vous avez la version de votre Google Doc dont on parlait tout à l'heure, de votre document complet. Vous avez la version la plus à jour, la plus fraîche, mais celle qui est aussi le plus fragile parce qu'elle a eu des tests unitaires, etc. Elle peut avoir plus ou moins de tests end-to-end et tout, selon le process de la boîte, mais elle est dans un environnement qui est prévu pour être cassée, en quelque sorte. OnDev, c'est vraiment votre environnement de bordel. Au-dessus, vous allez avoir... L'environnement dit de staging ou de pré-production, ça peut être deux environnements différents. Vous pouvez avoir un environnement dit de recette, un environnement de staging. Là, vous pouvez avoir plusieurs paliers, mais si on part du principe que vous en avez qu'un, c'est un environnement de pré-production. En gros, lui, il est là pour ressembler le plus possible à votre production. L'environnement de production étant celui que vous, vous avez dans les mains en tant qu'utilisateur et utilisatrice. Mais en fait derrière un environnement de production, ou un environnement des autres, il y a plus que juste l'écran et le bout de code, il y a aussi toute la partie infrastructure. Parce que concrètement, votre équipe de développeurs, s'ils sont 5, du coup ils n'ont pas besoin d'avoir énormément de ressources matérielles derrière pour faire tourner l'application. Ils n'ont besoin que d'une version légère. Mais en revanche sur la production, si vous avez 10 000 utilisateurs, il faut que derrière vous ayez des serveurs des ordinateurs, des machines, un réseau des mesures de sécurité des tests, des sauvegardes etc qui soient proportionnés pour supporter ces 10 000 utilisateurs et en fait le staging va être l'entre-deux votre environnement de pré-production il va être déjà plus sécurisé plus vérifié que l'environnement de dev il peut avoir éventuellement des données enfin pas pas forcément issus de la production, mais en tout cas qui reflètent des données de production, qui sont des données plus complètes, là où on dev, on va avoir un peu plus de données vraiment de tests, de brouillons, on va aussi avoir des vraies applications pour s'entraîner, mais voilà, qui va être un peu à part. Et votre staging, donc, c'est vraiment l'hybride de se dire, il doit ressembler le plus possible à la production en termes de type de données, en termes de type d'exemples, en termes de profil utilisateur, en termes de pas de nombre de gens, ça ne pourrait jamais répliquer autant, ou alors si, d'ailleurs je dis ça, mais il y a des tests qui permettent de le faire, mais voilà, c'est votre entre-deux, et justement, la fameuse mise en production, c'est de se dire, ok, donc sur staging, on a tout qui est bon, tout a été testé par le service qualité, tout est arrivé jusque-là, on s'est rendu compte aussi que sur notre environnement de staging, qui ressemble le plus possible à la prod, entre dev et là, on a eu un problème quand on est passé de l'un à l'autre, problème de déploiement, de... où, en fait, quand on a mis à jour, on s'est rendu compte qu'il y a un truc qui ne s'est pas bien passé côté infrastructure, parce qu'il y avait un tunnel qui était bouché, ou parce qu'il y avait un truc de réseau qui ne marchait pas bien, ou parce qu'il y avait une fonctionnalité qui marchait bien dans l'environnement de développement, mais en fait, sur l'environnement de pré-production, on se rend compte qu'il y a un truc qui ne passe pas et que, je ne sais pas moi, les administrateurs par exemple, peuvent plus se connecter à l'application. Voilà, c'est ce genre de choses qu'on va pouvoir identifier quand on passe d'un environnement à l'autre. Et l'idée, c'est qu'en staging, on verrouille tout ou quasiment tout, pour que quand on envoie en production, donc quand on fait la fameuse mise en production, le programme arrive, prêt, il tourne. On sait là où il peut y avoir des pépins et on est prêt à les corriger dans la foulée. On a vérifié que tout ce qui était critique est bon. On fait de la surveillance et on garde le tout à l'œil. Et pendant la mise en production, c'est le moment où les équipes sont au taquet, prêtes à intervenir. pour soit corriger les pépins s'il y en a au moment où ça arrive la mise à jour est terminée soit si, c'est le pire scénario, si la mise à jour elle casse tout et qu'on n'arrive pas à débloquer le cas, de pouvoir faire ce qu'on appelle un revert enfin revenir à une version antérieure et ça pareil, il y a plein de manières de revenir, enfin plusieurs manières en tout cas de revenir à la version antérieure mais de s'assurer que la production elle est coupée le moins longtemps possible si jamais elle doit avoir un mètre. Et j'ai parlé de recettes sans expliquer ce que c'était, mais en fait la recette ça va être un peu l'ensemble des scénarios qu'on doit valider avant d'envoyer en production. Donc de se dire, on a un panel de tests, où il y a, je viens de bêtise, 1000 tests possibles, et on va estimer que ces 1000 tests doivent être remplis avant d'envoyer en production, ou alors on va estimer qu'il n'y en a que 700 qui sont nécessaires, ou 300, etc. Après ça, ça va dépendre un peu d'eux. la tambouille de chaque boîte, le niveau de complexité, la criticité aussi de la mise à jour. En fait, il y a des mises à jour qu'on va envoyer en production et sur lesquelles on sait qu'il y a peu de risques et donc un panel de recettes plus léger peut être raté. accepté et ben nécessité moins de temps, moins de risques etc. Là où ben en fait justement si on a fait une refonte plusieurs refontes de se dire ah oui mais non là il faut vraiment que tout tout soit vérifié jusque le plus possible pour qu'on ait le moins de pépins possible arrivé. Voilà dans l'idée sur les trois gros environnement est ce que représente une mise en production et raison pour laquelle on évite de la faire le vendredi parce qu'en cas de pépins vous vous flinguez un bout de week-end Voilà, ça c'est dans les pires cas. Et de manière générale, une des bonnes pratiques de mise en production, c'est de le faire en dehors des horaires où vos utilisateurs sont sur l'application. Et scénario, encore idéal, si jamais vous êtes obligé de le faire, enfin le coquin n'est pas idéal, mais si jamais c'est obligé de le faire pendant des heures d'ouverture où les gens sont là, parce que ça va prendre trop de temps de faire les changements, quand il y a des grosses refontes, etc. On peut avoir un temps de coupure qui est absolument nécessaire. Et dans ces cas-là, on prévient à l'avance de se dire « Attention, ce jour-là, de telle heure à telle heure, il peut y avoir des perturbations parce qu'on met une nouvelle version. » Ou alors « Pendant de telle heure à telle heure, le produit sera juste complètement indisponible. » Et voilà, prenez vos mesures et soyez attentifs à ça. Et ce jour-là, vous pourrez. Aujourd'hui, même chose en fonction du domaine et du niveau d'importance de l'application. généralement il y a aussi des... je vais pas voir le terme mais en gros il y a tout un plan qui enfin il y a un nom pour les plans qui permettent de fonctionner en mode dégradé et donc quand justement l'application est pas disponible en entièreté ou est coupée pour x raisons de quand même pouvoir faire tourner le programme dans une manière plus légère pour pouvoir bosser parce qu'on peut dire en fait ce jour là j'ai des fonctionnalités qui marchent pas mais au moins je peux bosser de bout en bout et ça théoriquement il faudrait avoir ce concept-là dans toutes les boîtes, de se dire, est-ce qu'il y a un mode dégradé dans l'application que j'utilise qui me permettra de bosser dans tous les cas ? Et si jamais ce n'est pas le cas, est-ce que j'ai un plan B, tout simplement ? J'ai des outils de secours qui vont me permettre de bosser ? Je ne sais pas si tu as le terme en tête, Lulu, pour le plan de...
Manu
Non, je ne l'ai pas forcément, mais...
Lulu
Bon, j'essaierai de remettre la note dessus. En plus, il y en a quelqu'un dans la communauté de code qui... qui est spécialisé sur le sujet, qui en avait déjà pas mal parlé et fait du contenu dessus, mais je peux avoir l'appel à ça. Est-ce qu'on est bon sur la mise en production ? Et comme ça, on termine très rapidement pour la partie maintenance.
Manu
Ouais, ça me semble bien. Là, je pense que vous avez compris pourquoi est-ce que on développe pas sur la partie qui est en prod. Je pense que là, c'est à peu près bon. Est-ce que on connaît, tout le monde connaît quelqu'un qui le fait, qui l'a fait ? C'est d'autant plus vrai. à l'ère du vibe coding et développement par IA ou même l'application qui est en ligne et de se dire je vais juste faire un petit fixe,
Lulu
je vais juste changer un petit truc et au final ça casse tout et c'est plus accessible c'est effectivement le vibe coding donc le développement assisté par IA que même si vous bossez seul même si vous bossez, d'autant plus normalement si vous bossez en équipe vous avez déjà les bons réflexes mais si vous bossez seul et que vous découvrez prenez le temps de vous former sur les les méthodes et les techniques de développement, et ne serait-ce que, parce qu'en fait, ça s'applique aussi. Alors, vous n'êtes pas obligé d'avoir un staging au milieu, mais en fait, vous avez quand même besoin d'éprouver ce que vous faites sur un environnement de développement, donc généralement en local, sur votre machine, et ensuite de l'envoyer en production, donc vraiment sur la partie que les gens utilisent. Mais aussi, dans le vibe coding, il y a moyen d'avoir des environnements de pré-production. Par exemple, sur Supabase, qui est un outil qui fait back-end, donc base de données, authentification, plein de choses, permet d'avoir des branches qui sont conformes d'un point de vue infrastructure avec la production. Et du coup, vous pouvez soit faire vos tests en local, puis envoyer directement sur la prod une fois que c'est validé, soit faire vos tests en local, puis passer par une branche dite de preview et de là envoyer vers la production, soit faire un espace d'hybride où vous faites vos tests. directement sur la branche de preview, vu qu'elle est prévue pour ça, dans tous les cas. Et voilà, il y a plusieurs approches, mais en tout cas, même en white coding, et différents outils le permettent, Gano le permet, enfin, voilà. Il y a plusieurs approches, mais en tout cas, la notion d'environnement et de ne pas bosser directement sur ce que les gens ont dans les mains est fondamentale. Et après tout ça, donc, dernier point, dernière étape, votre application est en production. les gens s'en servent, la dernière chose qui reste, c'est la maintenance et le support. C'est là où on va repartir un petit peu dans un cycle comme on a... On va refaire un peu tout le cycle, en fait. C'est-à-dire que les gens vont vous signaler des soucis, soit des bugs, soit des choses qui seraient bien de faire évoluer, soit des choses qui manquent et qui auraient besoin de nouvelles fonctionnalités. Et ça va repartir dans l'étape recueil du besoin pour comprendre tout ce qu'on vous demande. Est-ce que c'est pertinent ou pas ? Comment on peut le faire ? Comment on peut le traduire ? Quand c'est le cas d'un bug, est-ce qu'il est important, pas important ? À quel niveau ? qu'est-ce que ça implique comme effort de développement pour le réparer rapidement ou pas. Et ça repart dans tout le cycle derrière, de développement, de relecture, de test, des différents environnements, etc. Et c'est pour ça que, de toute façon, même si un bug est corrigé le jour même, ça ne veut pas dire que vous l'aurez le jour même, parce qu'il faut qu'il repasse par toutes les étapes. Et qu'on ne fait pas une mise en production à la légère. Donc vous avez besoin... d'attendre généralement d'avoir plusieurs choses qui sont prêtes et développées en même temps avant de faire une mise en production. Et selon les boîtes, vous pouvez avoir une mise en production chaque semaine, chaque deux semaines, chaque mois, chaque deux mois, enfin du coup c'est très variable. Mais c'est ça le principe. Et sachant que chaque correction que vous pouvez faire peut vous amener d'autres effets de bord et d'autres problèmes à côté. D'où l'importance des tests et de chaque étape qu'on a citée au paradis. Et c'est aussi pour ça que dans les boîtes, vous aurez généralement les équipes de support. Et pour avoir bossé dans le support dans pas mal d'années et dans plusieurs boîtes, je vous confirme que généralement, les équipes de support sont celles avec les équipes de qualité qui connaissent le mieux le produit dans son entièreté, parce qu'elles sont amenées à travailler au contact des gens et des retours utilisateurs directement, donc au contact des métiers, un terme qu'on a déjà évoqué pas mal de fois, et en même temps qui manipulent un petit peu. tout le programme de bout en bout et donc ils sont les plus à même de dire et de savoir il y a ça qui ne marche pas mais en même temps on a une nouveauté à tel endroit qui doit pouvoir impacter ici ou alors il y a peut-être un contournement par tel biais et ainsi de suite et voilà d'où l'importance aussi de la communication entre les différents services dans les boîtes parce que au développement et d'autant plus quand la boîte va être plus grosse et le produit plus volumineux et qu'il va commencer à avoir de... du legacy, donc du code qui est hérité parce que le programme a 5 ans, 10 ans, 15 ans, 20 ans. C'est impossible d'avoir tout en tête à chaque fois qu'on fait quelque chose, peu importe le service. Et à ce titre-là, c'est de la communication entre les différents services qui va déterminer la qualité de votre produit et de votre application. Parce que si les infos transitent et que le support est en mesure de vous remonter, les choses qui vont et qui ne vont pas, et là où les utilisateurs râlent le plus, ou les pépins qu'ils ont le plus, la qualité... quand ils font les tests, si vous écoutez ce qu'ils vont vous dire et les évolutions et les ajustements qui seraient intéressants, c'est vraiment fondamental aussi et après les devs aussi ont leur mot à dire parce qu'ils sont complètement en mesure d'identifier quand il y a des problèmes de performance quand il y a des problèmes de des suggestions dites du hits par exemple un développeur qui va vous faire toute l'interface même si elle a été maquettée par un designer et par quelqu'un d'autre, peut très bien vous dire en fait là non vous m'avez donné ça comme consigne et je suis censé faire tel écran, mais en fait, il y a des choses pour moi qui ne vont pas à l'utilisation, ça va coincer pour telle et telle raison. Et voilà, donc à mon sens, la base d'une bonne application, ce sera la communication entre les différents intervenants d'un programme, de bout en bout, et de tenir compte du fait que chaque étape est importante et chaque personne que vous avez à chaque étape est importante.
Manu
Et c'est vrai que j'avais vu certaines boîtes justement où... Parfois, on peut avoir l'idée que les devs sont un peu déconnectés de ce qui se passe et comment le produit est utilisé. Et justement, de faire tourner les devs aussi sur le support pour qu'ils soient au contact des utilisateurs et de se dire, ça fait une, deux fois qu'on me demande ça. Bon, je n'ai pas envie qu'on me redemande la prochaine fois, donc je vais le corriger. Et ça peut donner d'autant plus de sens à un geste qui va être soit correctif, adaptatif ou perfectif. Ça, c'est les différentes modifications qu'on peut faire. Mais c'est là où c'est intéressant de pas juste rester cloisonné. C'est vrai que c'est quelque chose qui est assez français, de cloisonner les différents métiers, les différentes compétences. Là où, par contre, par exemple, aux États-Unis, ils vont plus travailler par feature. Donc là, ça va être vraiment, on va travailler sur une fonctionnalité et... Il y a du bon et du moins bon dans chaque modèle, mais parfois, on peut manquer un peu de prise de hauteur et de se dire comment est-ce que ça s'intègre. tout le parcours parce que forcément chaque... compétences, chaque personne va avoir un biais par rapport à ce qu'il fait et de se dire, moi c'est plus important alors que le support va dire autre chose, le développeur va dire autre chose et en même temps, côté marketing ils vont encore dire autre chose et voilà, il faut réussir à faire communiquer tout ça et encore une fois la communication, de s'ouvrir aussi même sans forcément savoir le faire et que ça devienne nos compétences, là c'est un peu ce qu'on essaye aussi de faire avec cet épisode, de donner les clés pour pour pouvoir communiquer avec quelqu'un qui le fera ou si on a envie de se mettre à développer, d'avoir ce qu'il faut en tête pour avancer et apprendre.
Lulu
Oui, et là, on n'a pas détaillé toutes les méthodes parce qu'on vous en doutait. Là, on vous a donné les grandes lignes de choses qui reviennent à chaque fois dans un développement d'application. Mais il y a plusieurs méthodes de le faire, plusieurs méthodes de travail en équipe, il y a plein d'organisations, il y a plein de... Et voilà, comme on l'a dit, en fonction de la taille de boîte, en plus, ça va jouer. Mais ce qui est important de retenir, c'est les différentes étapes qu'on vous a données aujourd'hui pour que vous ayez en tête que quand quelqu'un fait un programme, qu'il soit tout seul ou que ce soit une équipe de 10 ou de 20 ou de 2000, derrière, ce n'est pas juste j'ai besoin de ça et on le couche sur un écran une journée. Même quand c'est rapide, même quand c'est tout seul avec du développement assisté parier, etc. Il y a tout un cheminement à avoir, toute une logique à avoir si on veut faire les choses bien. Et c'est là où il faut être aussi méfiant et vigilant quand on fait du vibe coding. Ça ne veut pas dire qu'il ne faut pas faire de développement assisté par IA, ça ne veut pas dire que tout ce qui est fait en vibe coding sera mauvais ou sera bon, parce que si il est fait, il le fera bien et tout. On a déjà évoqué le sujet, l'IA reste un outil. Potentiellement un très bon exécutant, mais derrière, c'est à vous de driver et d'avoir en tête le chemin justement et les logiques. Je j'ose espérer. En tout cas, je vous souhaite que la prochaine fois que vous discutiez avec quelqu'un de votre boîte ou un collègue ou de la famille ou des amis qui bosse dans un des services qu'on a évoqués aujourd'hui, ce soit un peu moins obscur pour vous de savoir quel rôle il a dans le chemin d'une application en tout cas. Même si effectivement, on n'est pas rentré dans le détail de chaque service.
Manu
C'est de se dire que ce sont les grandes étapes d'un logiciel, mais après, ça peut être aussi une partie dans le logiciel. Et c'est là où on va justement arriver sur différents modèles, juste rapidement. Parce que je pense que tout le monde connaît l'agilité, la méthode agile. C'est vrai qu'on n'en a pas forcément parlé, mais là, ce qu'on a un petit peu décrit, c'est la méthode en cascade. même si c'est pas forcément celle qui qui me marche le mieux si on le fait à l'échelle d'un logiciel parce que là, c'est ok, on met des besoins, on développe, on développe, et puis à la fin le client, il a quelque chose et c'est potentiellement pas forcément ce qu'il attendait, donc c'est là où il...
Lulu
En fait, avec une approche itérative, t'as quand même ces cycles-là, d'une manière ou d'une autre.
Manu
Oui, mais en plus petit.
Lulu
Enfin, c'est... Ouais, en plus petit.
Manu
Sur un périmètre peut-être plus petit aussi. C'est ça, sur ton périmètre.
Lulu
c'est-à-dire que tu ne vas pas attendre 6 mois avant de donner ta première version, tu vas le faire, comme je disais, ça peut être une fois par semaine, toutes les deux semaines, tous les un mois, selon la taille de boîte et selon les versions. Mais ce cycle-là de développement, de test, de mise en prod, etc., tout ça, il faut quand même y passer, le recueil des besoins aussi. Mais c'est vrai que dans la partie itérative, quand on va penser une nouvelle fonctionnalité, le recueil des besoins, on va le faire différemment. On va aller discuter avec les gens, on va aller faire... des fois des maquettes ou des prototypes qu'on va leur mettre dans les mains, qui ne seront pas dans la version finale que tout le monde utilise, mais qui seront réservées à un petit groupe d'utilisateurs et d'utilisatrices qui vont pouvoir utiliser cette version-là un peu bricolée et dire « en fait, ça, ça marche bien, ça, ça ne marche pas bien » . Et à partir de là, on va développer la vraie version qui sera intégrée au logiciel. Et dans les parties recueil de besoins, justement, ça va être plus ou moins long. Dans la partie développement, ça va être sur le prototype qui sera plus ou moins gros, qui sera intégré à une prochaine version. En tout cas, les grandes étapes sont là, même en mode itératif et même avec d'autres approches, mais effectivement avec des durées différentes, avec des périmètres différents et avec des actions qui peuvent être un peu différentes aussi.
Manu
Il n'y a pas une méthode qui est meilleure que les autres. Ça va vraiment dépendre du type de logiciel développé, du type d'équipe. Il y a même des moments où la cascade ou le cycle en V reste pertinent par rapport... à une méthode agile, même mal appliquée, où on va faire un peu d'agilité de façade, ou du scrum. Il y a certains... contextes, notamment réglementaires ou alors qui vont toucher à toute la partie hardware, qui vont faire qu'un framework de développement sera plus pertinent qu'un autre. Donc c'est pas genre, si je me mets à développer, il faut forcément que ce soit avec une méthode agile. Il faut aussi se poser ces questions, c'est comme un peu dire il y a un meilleur outil qu'un autre, il y a un meilleur langage qu'un autre pour développer. A chaque fois, c'est en fonction, c'est qu'un outil qui va répondre. qui va aider à répondre du mieux possible à un besoin. Comme il y a, voilà, si elle peut être pertinente, c'est bien, mais ce n'est pas forcément une finalité.
Lulu
Oui, on est vraiment d'accord. Bon, on a fait notre plus gros et plus long numéro jusqu'à présent, mais au moins, vous avez le chemin complet. J'espère que ça vous aura plu.
Manu
Il y a toute la partie sécurité aussi, mais ça, on peut le mettre dans les tests. Il y aurait, mais après,
Lulu
il y aurait... Mais voilà. Le bon logiciel, ce n'est pas infini, mais oui, il y aurait la partie sécurité, il y aurait la partie sauvegarde, mais tu as d'autres choses dans la maintenance, dans le support.
Manu
C'est ça, mais ça, c'est comme on a dit pour les tests, il faut aussi la penser à chaque étape. Ce n'est pas à la fin, on vérifie que notre application est sécurisée. On va demander à Cloud Code, on vérifie si l'application est sécure et que c'est bon, les gens peuvent effectuer des paiements, créer des comptes sans souci dessus. Non, c'est aussi à chaque étape et ça inclure aussi dans les tests.
Lulu
Parfait. Merci Lulu de m'avoir accompagné sur cet épisode. On se retrouve la semaine prochaine pour la suite de notre épisode côté outils sur le développement de notre portail. Maintenant qu'on vous a expliqué tout ça, ce sera beaucoup plus simple à suivre. Et rassurez-vous, l'épisode sur la suite du portail sera plus court.
Manu
J'espère qu'il sera plus court maintenant qu'on a pris le temps de tout expliquer. Oui, on a déjà fait une première moitié. pour vraiment aller montrer comment on a mis les mains dans le cambouis et puis avec des côtés, enfin outils là pour le coup.
Lulu
Oui.
Manu
Voilà.
Lulu
Merci à tous et à toutes de nous avoir écoutés. On vous souhaite une bonne journée ou bonne fin de journée selon quand vous nous écouterez et on se retrouve la semaine prochaine avec Lulu.
Manu
Salut.

Chapters

À l'ère du vibe coding, tout le chemin derrière un logiciel
10sec
Le recueil des besoins : métiers, existant, fonctionnel et non-fonctionnel
4min
Conception : PRD, user stories et le découpage en briques
20min
Développement et versionnage : Git, GitHub, branches et pull requests
30min
Les familles de tests, la dette technique et les refontes
44min
Mise en production, maintenance et modèles de développement
1h14

About Le Dernier Clic (avant la fin du monde)

Le Dernier Clic c'est un podcast Tech, IA et No-Code où on prend un moment pour se poser sur les sujets tech et réfléchir à ce qu'on en fait.

On alterne chaque semaine : un épisode thématique où on creuse un sujet, et un épisode orienté outils, où on vous parle de ce qu'on utilise vraiment au quotidien et pourquoi.

Nous sommes Lucile Mothiron et Emmanuel Fernandez, deux adeptes de la tech quand elle est utile, ravis de vous embarquer avec nous pour cette première saison du Dernier Clic.

Hébergé par Ausha. Visitez ausha.co/politique-de-confidentialite pour plus d'informations.

About Le Dernier Clic (avant la fin du monde)

Le Dernier Clic c'est un podcast Tech, IA et No-Code où on prend un moment pour se poser sur les sujets tech et réfléchir à ce qu'on en fait.

On alterne chaque semaine : un épisode thématique où on creuse un sujet, et un épisode orienté outils, où on vous parle de ce qu'on utilise vraiment au quotidien et pourquoi.

Nous sommes Lucile Mothiron et Emmanuel Fernandez, deux adeptes de la tech quand elle est utile, ravis de vous embarquer avec nous pour cette première saison du Dernier Clic.

Hébergé par Ausha. Visitez ausha.co/politique-de-confidentialite pour plus d'informations.

Embed

À l'ère du vibe coding, tout le chemin derrière un logiciel

10sec

Le recueil des besoins : métiers, existant, fonctionnel et non-fonctionnel

4min

Conception : PRD, user stories et le découpage en briques

20min

Développement et versionnage : Git, GitHub, branches et pull requests

30min

Les familles de tests, la dette technique et les refontes

44min

Mise en production, maintenance et modèles de développement

1h14

Chapters

À l'ère du vibe coding, tout le chemin derrière un logiciel

10sec

Le recueil des besoins : métiers, existant, fonctionnel et non-fonctionnel

4min

Conception : PRD, user stories et le découpage en briques

20min

Développement et versionnage : Git, GitHub, branches et pull requests

30min

Les familles de tests, la dette technique et les refontes

44min

Mise en production, maintenance et modèles de développement

1h14