{"id":82738,"date":"2019-01-09T10:50:00","date_gmt":"2019-01-09T15:50:00","guid":{"rendered":"https:\/\/www.applause.com\/blog\/approche-agile-faire-pousser-logiciel\/"},"modified":"2025-07-21T11:22:23","modified_gmt":"2025-07-21T15:22:23","slug":"approche-agile-faire-pousser-logiciel","status":"publish","type":"post","link":"https:\/\/www.applause.com\/fr\/blog\/approche-agile-faire-pousser-logiciel\/","title":{"rendered":"L&rsquo;approche Agile : comment faire pousser son produit logiciel en pratique ?"},"content":{"rendered":"<div class=\"et_pb_section_0 et_pb_section et_section_regular et_flex_section preset--module--divi-section--31615dad-3f88-477f-a866-c2b40c889be5\"><div class=\"et_pb_row_0 et_pb_row et_flex_row\"><div class=\"et_pb_column_0 et_pb_column et-last-child et_flex_column et_pb_css_mix_blend_mode_passthrough et_flex_column_24_24 et_flex_column_24_24_tablet et_flex_column_24_24_phone et_flex_column_24_24_phoneWide et_flex_column_24_24_tabletWide et_flex_column_24_24_widescreen et_flex_column_24_24_ultraWide\"><div class=\"et_pb_text_0 et_pb_text et_pb_bg_layout_light et_pb_module et_flex_module preset--group--divi-text--divi-font-body--default preset--group--divi-text--divi-font-body--h19rs5u--default preset--group--divi-text--divi-font-body--h1yjkjr--default preset--module--divi-text--4564d33f-bb24-4931-8445-a739e42249ca\"><div class=\"et_pb_text_inner\"><h1>L\u2019approche Agile : comment faire pousser son produit logiciel en pratique ?<\/h1>\n<p><a role=\"link\" href=\"https:\/\/www.applause.com\/fr\/blog\/developpement-agile-faire-pousser\/\" target=\"_blank\" rel=\"noreferrer noopener\">Dans mon pr\u00e9c\u00e9dent article<\/a>\u00a0je vous exposais comment cela ne faisait pas sens de construire un logiciel et qu\u2019\u00e0 la place il fallait le faire pousser, pour pouvoir tirer parti de la nature-m\u00eame du logiciel : versatile, flexible et facile \u00e0 mettre \u00e0 jour.\u00a0<strong>Ce second article se penche sur la mise en place en pratique de cette approche.<\/strong><\/p>\n<h3><strong>Faire pousser le logiciel : Comment commencer ?<\/strong><\/h3>\n<h4><strong>Premi\u00e8re \u00e9tape : le cas d\u2019utilisation<\/strong><\/h4>\n<p>Il est essentiel de commencer par un unique cas d\u2019utilisation qui fonctionnera de bout en bout.<\/p>\n<p><strong>Ce cas d\u2019utilisation doit \u00eatre vertical :<\/strong>\u00a0le but est de traverser toutes les couches du logiciel. Le travail \u00e0 r\u00e9aliser contiendra donc une petite tranche de chaque couche. Par exemple, dans le cas d\u2019une application Web, le cas d\u2019utilisation devrait comprendre \u00e0 la fois le front-end et le back-end, les couches de donn\u00e9es et de pr\u00e9sentation sur le front-end, et les couches de base de donn\u00e9es et de traitement des donn\u00e9es sur le back-end.<\/p>\n<p><strong>Il doit \u00e9galement \u00eatre typique<\/strong>\u00a0dans le sens o\u00f9 ce cas d\u2019utilisation testera les plus gros risques identifi\u00e9s. On veut s\u2019assurer que les risques sont sous contr\u00f4le. En particulier, les diff\u00e9rentes couches du logiciel doivent \u00eatre int\u00e9gr\u00e9es entre elles.<\/p>\n<p><strong>Vous voudrez \u00e9galement que ce cas d\u2019utilisation soit le plus basique possible<\/strong>\u00a0: tout en \u00e9tant vertical et typique, vous voudrez qu\u2019il apporte le moins de changement possible\u2026 Car le but est de le faire rapidement ! C\u2019est pourquoi votre premier cas d\u2019utilisation sera basique afin d\u2019obtenir rapidement des retours.<\/p>\n<p>\u00c0 premi\u00e8re vue, ce premier cas d\u2019utilisation n\u2019est qu\u2019un embryon de fonctionnalit\u00e9 qui n\u2019apporte que peu de valeur. Et pourtant :<\/p>\n<ul>\n<li>Ce cas d\u2019utilisation apporte r\u00e9ellement de la valeur, m\u00eame si ce n\u2019est qu\u2019un petit peu<\/li>\n<li>Il est d\u00e9montrable, ce qui veut dire que cette valeur fait sens pour les utilisateurs \u2014 et vous allez pouvoir obtenir des retours dessus !<\/li>\n<li>Il a aid\u00e9 \u00e0 la conception du logiciel en prenant en compte les enjeux majeurs et en s\u2019assurant que les risques sont g\u00e9r\u00e9s. Ainsi, la suite du d\u00e9veloppement se d\u00e9roulera sans accroc<\/li>\n<li>Et enfin cette valeur est apport\u00e9e rapidement, ce qui compense largement le fait que seulement un minimum de valeur soit produite<\/li>\n<\/ul>\n<h4><strong>Deuxi\u00e8me \u00e9tape : on fait pousser le logiciel<\/strong><\/h4>\n<p>Une fois qu\u2019on a cet embryon qui fonctionne, on peut r\u00e9ellement passer \u00e0 la phase o\u00f9 on\u00a0<em>fait pousser<\/em>\u00a0le logiciel tel que d\u00e9crit\u00a0<a role=\"link\" href=\"https:\/\/www.applause.com\/fr\/blog\/developpement-agile-faire-pousser\/\" target=\"_blank\" rel=\"noreferrer noopener\">dans le pr\u00e9c\u00e9dent article<\/a>\u00a0:<\/p>\n<ul>\n<li>N\u2019ajouter que des petits changements qui apportent toujours de la valeur<\/li>\n<li>S\u2019assurer que les changements et leur valeur sont toujours d\u00e9montrables<\/li>\n<li>Toujours int\u00e9grer ces changements avec le reste du logiciel<\/li>\n<li>Ces changements peuvent \u00eatre effectu\u00e9s sur les diff\u00e9rentes parties du logiciel, sans mettre en danger l\u2019ensemble du logiciel<\/li>\n<\/ul>\n<p>\u00c0 n\u2019importe quel moment, si on fait fausse route, il est toujours possible de revenir \u00e0 un pr\u00e9c\u00e9dent \u00e9tat bien connu. C\u2019est facile parce que les \u00e9tapes sont petites. Et si vous devez jeter votre code, \u00e7a ne pose aucun probl\u00e8me. En effet, vous ne jetez qu\u2019une petite quantit\u00e9 de travail.<\/p>\n<blockquote class=\"blog-quote \">\n<div class=\"quote-container\">\n<p class=\"quote-text\">Quand on fait pousser le logiciel, il est facile de revenir en arri\u00e8re car les \u00e9tapes sont petites. Et si vous devez jeter votre code, vous ne jetez qu\u2019une petite quantit\u00e9 de travail.<\/p>\n<\/div>\n<\/blockquote>\n<p><strong>La gestion de produit : travailler en petits incr\u00e9ments<\/strong><\/p>\n<h3><strong>Des contraintes claires de d\u00e9coupage<\/strong><\/h3>\n<p>En faisant pousser le logiciel, les contraintes de d\u00e9coupage des \u00e9l\u00e9ments du backlog sont claires :<\/p>\n<ul>\n<li>Le logiciel doit \u00eatre vivant \u00e0 tout moment : d\u00e9montrable et pleinement int\u00e9gr\u00e9<\/li>\n<li>Tous les \u00e9l\u00e9ments du backlog doivent bien apporter de la valeur<\/li>\n<li>Il faut d\u00e9couper les \u00e9l\u00e9ments du backlog afin d\u2019obtenir du feedback le plus vite possible<\/li>\n<\/ul>\n<h4><strong>Adopter le bon \u00e9tat d\u2019esprit de d\u00e9veloppement logiciel<\/strong><\/h4>\n<p>Quelles sont les implications de cette mani\u00e8re de penser ?<\/p>\n<ul>\n<li>La premi\u00e8re phase de travail doit permettre d\u2019obtenir un logiciel vivant mais aussi de s\u2019assurer que l\u2019architecture logicielle est adapt\u00e9e<\/li>\n<li>Tout en faisant bien attention \u00e0 ne pr\u00e9voir que le strict minimum : il faut faire marcher le logiciel en minimisant les efforts n\u00e9cessaires<\/li>\n<li>Et tout cela en restant pr\u00eat \u00e0 jeter n\u2019importe quel morceau de code qui emp\u00eacherait le logiciel de pousser facilement<\/li>\n<\/ul>\n<h4><strong>Les principes-m\u00eames de la gestion de produit<\/strong><\/h4>\n<p>En fin de compte, l\u2019approche de faire pousser un logiciel correspond compl\u00e8tement \u00e0 une bonne gestion de produit :<\/p>\n<ul>\n<li>Concevoir de petites fonctionnalit\u00e9s, les tester, et ensuite les am\u00e9liorer \u2014 ce qui correspond \u00e0\u00a0<a role=\"link\" href=\"https:\/\/www.applause.com\/fr\/blog\/experimentation-lean-startup-produit\/\" target=\"_blank\" rel=\"noreferrer noopener\">l\u2019approche Lean Startup que je d\u00e9crivais dans un pr\u00e9c\u00e9dent article<\/a><\/li>\n<\/ul>\n<ul>\n<li>Pour y arriver, on travaille par petits incr\u00e9ments et on it\u00e8re le plus rapidement possible<\/li>\n<li>S\u2019assurer que les risques sont bien pris en compte, pour ne pas mettre en danger la vitesse de d\u00e9veloppement du produit<\/li>\n<li>Ne pas perdre son temps \u00e0 faire ce qui n\u2019apporte pas de valeur<\/li>\n<\/ul>\n<hr \/>\n<p><strong><em>Pour en savoir plus sur comment tester son logiciel de mani\u00e8re agile, consultez notre page sur le\u00a0<a role=\"link\">testing agile<\/a><\/em><\/strong><\/p>\n<hr \/>\n<h3><strong>Quels risques \u00e0 ne pas adopter ce mindset ?<\/strong><\/h3>\n<p>Voici les risques que vous encourez si dans votre progression vers l\u2019Agilit\u00e9 vous continuez malgr\u00e9 tout de fonctionner en pensant\u00a0<em>construction\u00a0<\/em>plut\u00f4t que\u00a0<em>faire pousser<\/em>\u00a0:<\/p>\n<ul>\n<li>Vous pensez avoir adopt\u00e9 l\u2019Agilit\u00e9 et vous en avez adopt\u00e9 les pratiques, mais votre fonctionnement produit reste inchang\u00e9.<\/li>\n<li>Votre capacit\u00e9 \u00e0 mettre en production est limit\u00e9e. Vous pr\u00e9voyez explicitement les moments de mise en production plut\u00f4t que d\u2019avoir en permanence une base de code potentiellement livrable. R\u00e9sultat imm\u00e9diat : chaque mise en production s\u2019accompagne de son lot d\u2019impr\u00e9vus et de mauvaises surprises.<\/li>\n<li>Le produit n\u2019est pas con\u00e7u pour \u00eatre \u00e9volutif : plus la base de code augmente et plus il devient difficile de la modifier. L\u2019\u00e9quipe devient de moins en moins pr\u00e9dictible, les estimations explosent. Les d\u00e9veloppeurs se plaignent d\u00e8s qu\u2019une nouvelle demande arrive\u2026<\/li>\n<li>Face au manque d\u2019\u00e9volutivit\u00e9 du produit, tout le syst\u00e8me se rebelle contre le m\u00e9tier ou les utilisateurs afin de limiter au maximum les \u00e9volutions. Par exemple, le Definition of Ready devient de plus en plus strict et proc\u00e9durier. Ou encore, on commence \u00e0 parler de \u201cscope creep\u201d pour indiquer les demandes qui n\u2019\u00e9taient pas pr\u00e9vues au d\u00e9part alors qu\u2019elles correspondent au besoin r\u00e9el, inconnu jusqu\u2019ici.<\/li>\n<li>L\u2019\u00e9quipe d\u00e9veloppe un \u00e9tat d\u2019esprit d\u2019ex\u00e9cutant, traitant une liste de t\u00e2ches, plut\u00f4t que de penser au r\u00e9el sens du produit, au service qu\u2019il doit rendre\u2026<\/li>\n<\/ul>\n<p>Quand on y pense, passer \u00e0 l\u2019Agilit\u00e9 et continuer \u00e0 construire plut\u00f4t que de commencer \u00e0 faire pousser, cela revient \u00e0 continuer de travailler comme avant !<\/p>\n<h3><strong>Prenons exemple sur la nature<\/strong><\/h3>\n<p>Pour conclure, l\u2019analogie avec la nature n\u2019est pas anodine : celle-ci est tellement complexe qu\u2019analyser les \u00e9l\u00e9ments fondamentaux qui ont permis \u00e0 la vie de s\u2019\u00e9panouir est certainement le meilleur moyen d\u2019aborder le probl\u00e8me de la complexit\u00e9 dans la gestion des projets logiciels.\u00a0<strong>Nous sommes simplement en train de red\u00e9couvrir ce que la nature a d\u00e9couvert par elle-m\u00eame il y a des milliards d\u2019ann\u00e9es\u2026<\/strong><\/p>\n<\/div><\/div><\/div><\/div><\/div>","protected":false},"excerpt":{"rendered":"<p>Second article sur l&rsquo;approche Agile. Apr\u00e8s la th\u00e9orie, passons \u00e0 la pratique et adoptons concr\u00e8tement l&rsquo;approche \u00ab\u00a0faire pousser\u00a0\u00bb.<\/p>\n","protected":false},"author":42,"featured_media":74791,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[996,281],"tags":[983],"resource-industry":[],"resource-solution":[],"resources\/types":[1242],"class_list":["post-82738","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-crowdtesting","category-non-classifiee","tag-agile","resource-type-blogues"],"acf":[],"_links":{"self":[{"href":"https:\/\/www.applause.com\/fr\/wp-json\/wp\/v2\/posts\/82738","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.applause.com\/fr\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.applause.com\/fr\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.applause.com\/fr\/wp-json\/wp\/v2\/users\/42"}],"replies":[{"embeddable":true,"href":"https:\/\/www.applause.com\/fr\/wp-json\/wp\/v2\/comments?post=82738"}],"version-history":[{"count":0,"href":"https:\/\/www.applause.com\/fr\/wp-json\/wp\/v2\/posts\/82738\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.applause.com\/fr\/wp-json\/wp\/v2\/media\/74791"}],"wp:attachment":[{"href":"https:\/\/www.applause.com\/fr\/wp-json\/wp\/v2\/media?parent=82738"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.applause.com\/fr\/wp-json\/wp\/v2\/categories?post=82738"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.applause.com\/fr\/wp-json\/wp\/v2\/tags?post=82738"},{"taxonomy":"resource-industry","embeddable":true,"href":"https:\/\/www.applause.com\/fr\/wp-json\/wp\/v2\/resource-industry?post=82738"},{"taxonomy":"resource-solution","embeddable":true,"href":"https:\/\/www.applause.com\/fr\/wp-json\/wp\/v2\/resource-solution?post=82738"},{"taxonomy":"resource-type","embeddable":true,"href":"https:\/\/www.applause.com\/fr\/wp-json\/wp\/v2\/resources\/types?post=82738"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}