{"id":152,"date":"2012-02-26T20:19:27","date_gmt":"2012-02-26T19:19:27","guid":{"rendered":"http:\/\/dev.qualilogy.com\/fr\/?p=152"},"modified":"2013-01-04T20:23:29","modified_gmt":"2013-01-04T19:23:29","slug":"dette-technique-developpeurs-vs-marketeux","status":"publish","type":"post","link":"http:\/\/qualilogy.com\/fr\/dette-technique-developpeurs-vs-marketeux\/","title":{"rendered":"Dette technique &#8211; D\u00e9veloppeurs vs. marketeux"},"content":{"rendered":"<p><a href=\"http:\/\/vicken.deviantart.com\/\" target=\"_blank\"><img loading=\"lazy\" decoding=\"async\" class=\"alignright size-full wp-image-1192\" title=\"Qual_TechDebt1\" src=\"http:\/\/qualilogy.com\/wp-content\/uploads\/2012\/02\/Qual_TechDebt1.jpg\" alt=\"\" width=\"239\" height=\"360\" \/><\/a>Je dois vous faire un aveu : je me suis toujours m\u00e9fi\u00e9 de la notion de dette technique. Cela m\u2019a toujours paru un concept marketing.<\/p>\n<p>C\u2019est comme si vous d\u00e9cidiez d\u2019acheter une voiture, que le vendeur vous remette fi\u00e8rement les cl\u00e9s et ajoute avec un petit sourire : \u00ab vous devez d\u00e9j\u00e0 10 000 $ \u00bb. Et il ne parle pas du cr\u00e9dit auto, non, il veut simplement dire que la voiture que vous venez d\u2019acheter comporte certains d\u00e9fauts qui vont devenir de plus en plus apparents au fil du temps, fatigueront le moteur, la carrosserie, voire m\u00eame probablement le conducteur.<\/p>\n<p>Quelle serait votre r\u00e9action si un vendeur vous disait cela ? Accepteriez-vous d\u2019acheter cette voiture ?<\/p>\n<p><!--more-->D\u2019accord, je sais que l\u2019achat d\u2019une voiture, d\u2019une maison, de tout bien co\u00fbteux car complexe et long \u00e0 produire s\u2019accompagne de frais d\u2019entretien, de r\u00e9vision, bref de maintenance. En ce sens, j\u2019aime bien le pouvoir explicatif de l\u2019analogie et d\u2019ailleurs, le d\u00e9veloppement logiciel a souvent \u00e9t\u00e9 compar\u00e9 \u00e1 la construction d\u2019une habitation.<\/p>\n<p>Mais tout le monde conna\u00eet l\u2019histoire : lorsque Ward Cunningham invente ce concept en 1992, il passe relativement inaper\u00e7u, tout au moins hors de la communaut\u00e9 des d\u00e9veloppeurs, jusqu\u2019\u00e0 ces derni\u00e8res ann\u00e9es o\u00f9, boum, la dette technique se transforme en une v\u00e9ritable explosion m\u00e9diatique et vraiment, cela fait peur. Selon Gartner, elle atteignait 500 milliards de $ en 2010 et devrait doubler d\u2019ici \u00e0 2015. Avec une telle inflation, elle sera sup\u00e9rieure \u00e0 la dette souveraine de la Russie en 2020. Quelle angoisse.<\/p>\n<p>La dette technique est un r\u00eave de marketeux parce que :<\/p>\n<ul>\n<li>C\u2019est technique, donc c\u2019est vraisemblable, et pose en expert celui qui en parle.<\/li>\n<li>Cela appelle l\u2019attention : vous devez de l\u2019argent \u2013 beaucoup \u2013 et vous ne le saviez pas.<\/li>\n<li>Cela se pr\u00eate \u00e0 toutes sortes d\u2019exercices et de prolongement tr\u00e8s cr\u00e9atifs : plafond de la dette, calcul des int\u00e9r\u00eats, estimation de point mort, r\u00e9duction du risque syst\u00e9mique, etc. Tr\u00e8s inventive : la notion de code ou d\u2019application toxique. Je me demande s\u2019ils fournissent le masque \u00e0 gaz aux d\u00e9veloppeurs.<\/li>\n<\/ul>\n<p>Comme l\u2019explique Ward Cunningham (<a title=\"Ward Explains Debt Metapho\" href=\"http:\/\/c2.com\/cgi\/wiki?WardExplainsDebtMetaphor\" target=\"_blank\">Ward Explains Debt Metaphor<\/a>), il a utilis\u00e9 la m\u00e9taphore de la dette technique pour justifier aupr\u00e8s de son patron le refactoring r\u00e9alis\u00e9 sur le produit financier qu\u2019ils d\u00e9veloppaient. En empruntant au d\u00e9but, il est possible d\u2019aller plus vite, mais on doit ensuite payer les int\u00e9r\u00eats. Comme d\u00e9velopper son entreprise : si vous pouvez emprunter, vous pourrez embaucher plus de monde, investir dans plus de points de vente, disposer d\u2019un budget publicitaire, etc. Vous grandirez plus rapidement mais vous ne pouvez pas emprunter continuellement car sinon les int\u00e9r\u00eats et le remboursement de votre dette finiront par devenir votre principal poste de d\u00e9pense et vous emp\u00eacher toute croissance.<\/p>\n<p>Ward explique \u00e9galement que ses propos ont \u00e9t\u00e9 repris de mani\u00e8re confuse, pour ne pas dire erron\u00e9e. Il insiste sur le fait qu\u2019un code doit \u00eatre \u00e9crit correctement d\u00e9s le d\u00e9part afin de permettre ensuite le refactoring. Emprunter ne signifie pas \u00e9crire du code de pi\u00e8tre qualit\u00e9 afin de sortir l\u2019application en temps et en heure malgr\u00e9 les retards du projet ou les erreurs de planning, sinon d\u00e9velopper rapidement des versions fr\u00e9quentes (Extreme Programming) et inscrire le refactoring du code dans le cycle de vie du projet.<\/p>\n<p>Ward Cunnigham est un d\u00e9veloppeur qui, comme il l\u2019explique lui-m\u00eame, a utilis\u00e9 le concept de dette technique en tant que m\u00e9taphore. Il existe 2 types de m\u00e9taphores :<\/p>\n<ul>\n<li>Celles au pouvoir descriptif, qui permettent de comprendre un concept par l\u2019illustration, la comparaison avec un autre concept.<\/li>\n<li>Celles au pouvoir pr\u00e9dictif, qui permettent de pr\u00e9dire un certain comportement et de d\u00e9couvrir de nouvelles lois.<\/li>\n<\/ul>\n<p>Par exemple, on vous demande d\u2019expliquer ce qu\u2019est un atome. Vous pouvez effectuer une analogie avec une plan\u00e8te qui tourne autour de son soleil, tel des \u00e9lectrons autour de leur noyau. Ce serait une analogie du premier type.<\/p>\n<p>Si maintenant vous d\u00e9cidez de construire une mod\u00e9lisation d\u2019un syst\u00e8me solaire, en un ensemble d\u2019objets (plan\u00e8te, soleil), d\u2019attributs (masse) et de relations (attraction), et si vous utilisez celle-ci pour en d\u00e9duire une nouvelle mod\u00e9lisation entre les \u00e9lectrons et leur noyau qui permette de pr\u00e9dire leur comportement, alors il s\u2019agira d\u2019une analogie du second type.<\/p>\n<p>La m\u00e9taphore de Ward Cunnigham est un outil explicatif tr\u00e8s puissant, mais il ne s\u2019agit pas d\u2019une mod\u00e9lisation dont on pourrait tirer de nouvelles lois. Son int\u00e9r\u00eat principal r\u00e9side dans l\u2019id\u00e9e d\u2019inscrire le refactoring de mani\u00e8re continue dans le cycle de vie d\u2019une application. Pr\u00e9tendre qu\u2019il est possible de chiffrer la dette technique, de calculer son co\u00fbt \u00e0 la ligne de code, d\u2019\u00e9valuer les int\u00e9r\u00eats de cette dette afin d\u2019estimer \u00e0 quel point de la courbe celle-ci devient trop lourde, c\u2019est du marketing.<\/p>\n<p>D\u2019ailleurs, ce n\u2019est pas innocent si les chiffres avanc\u00e9s sont g\u00e9n\u00e9ralement effrayants et en croissance d\u2019une ann\u00e9e sur l\u2019autre. Pourquoi croyez-vous que votre application de 300 000 lignes de code pr\u00e9sente une dette technique d\u20191 million de $ avant m\u00eame que qui que ce soit se penche dessus et regarde quel est vraiment son niveau de non-qualit\u00e9 ? Combien seriez- vous pr\u00eat \u00e1 d\u00e9penser pour r\u00e9duire cette dette ? 100 000 $ ? 200 000$ ?<\/p>\n<p>Les d\u00e9veloppeurs l\u2019ont bien compris. La dette technique repr\u00e9sente :<\/p>\n<ul>\n<li>L\u2019id\u00e9e que le code doive \u00eatre r\u00e9guli\u00e8rement refactoris\u00e9 afin de limiter la non-qualit\u00e9 \u00e1 un niveau acceptable<\/li>\n<li>Un indicateur int\u00e9ressant qui introduit une notion d\u2019effort et de co\u00fbt de correction.<\/li>\n<\/ul>\n<p>Si vous avez le choix entre corriger un d\u00e9faut critique pour un co\u00fbt tr\u00e8s bas et corriger un d\u00e9faut peu important pour un co\u00fbt \u00e9lev\u00e9, vous n\u2019allez \u00e9videmment pas h\u00e9siter tr\u00e8s longtemps.<br \/>\nA ce titre, la dette technique peut constituer un outil d\u2019aide \u00e0 la d\u00e9cision, mais en n\u2019oubliant jamais qu\u2019il ne s\u2019agit pas d\u2019un vrai co\u00fbt financier et en sachant l\u2019interpr\u00e9ter correctement. Quelques exemples.<\/p>\n<p>Vous pouvez utiliser la dette technique comme indicateur au sein d\u2019un SLA pour un fournisseur, mais de mani\u00e8re diff\u00e9rente selon la nature des d\u00e9veloppements :<\/p>\n<ul>\n<li>Nouveau d\u00e9veloppement : une dette technique nulle n\u2019aurait pas de sens, toute nouvelle application m\u00eame tr\u00e8s bien \u00e9crite comportera forc\u00e9ment un minimum de composants tr\u00e8s complexes ou volumineux ou avec beaucoup de liens entre eux. Il faut simplement faire en sorte que leur nombre reste raisonnable. Vous d\u00e9finirez donc avec votre fournisseur un niveau de dette technique qu\u2019il ne doit pas d\u00e9passer.<\/li>\n<li>Maintenance : votre fournisseur n\u2019est pas responsable de la dette technique existante sur une application d\u00e9velopp\u00e9e par quelqu\u2019un d\u2019autre que lui. Il doit simplement \u00e9viter que celle-ci ne devienne plus importante. Ici, pas question de fixer un seuil de dette technique \u00e0 ne pas franchir sinon \u00e9viter de faire cro\u00eetre celle-ci. Vous pouvez m\u00eame inciter votre fournisseur \u00e1 la diminuer \u00e1 l\u2019aide de bonus.<\/li>\n<\/ul>\n<p>Alignez votre dette technique sur vos objectifs IT, eux-m\u00eames align\u00e9s sur les objectifs de l\u2019entreprise. Nous l\u2019avons d\u00e9j\u00e0 vu dans le post &lsquo;<a title=\"Best of both worlds\" href=\"http:\/\/qualilogy.com\/fr\/best-of-both-worlds\" target=\"_blank\">Best of both worlds&rsquo;<\/a>, une politique de tol\u00e9rance z\u00e9ro pour des violations de performance n\u2019a pas de sens lorsque le plus important consiste \u00e1 ne pas d\u00e9passer les budgets. A l\u2019inverse, si l\u2019argent n\u2019est pas un probl\u00e8me mais que l\u2019application doit fonctionner correctement en temps et en heure, les d\u00e9fauts en mati\u00e8re de performance et de robustesse et le time-to-market deviennent critiques. Construisez vos plans d\u2019action en fonction des objectifs, puis ensuite seulement en fonction de la dette critique, pas l\u2019inverse.<\/p>\n<p>Laissez suffisamment de latitude aux \u00e9quipes de projet pour d\u00e9cider d\u2019eux-m\u00eames des actions de refactoring, mais d\u00e9finissez avec eux un objectif en mati\u00e8re de dette technique et incluez-le dans une Quality Gate. G\u00e9n\u00e9ralement, les d\u00e9veloppeurs seront efficaces en ce sens qu\u2019ils optimiseront leurs actions de refactoring en corrigeant les d\u00e9fauts les plus graves mais les moins co\u00fbteux en charges de travail. Cela suppose n\u00e9anmoins qu\u2019ils soient outill\u00e9s pour pouvoir \u00e9valuer la dette technique. Sur ce point, voir notre post &lsquo;<a title=\"10 to 20 metrics\" href=\"http:\/\/qualilogy.com\/fr\/10-a-20-metriques\" target=\"_blank\">10 to 20 metrics&rsquo;<\/a>.<\/p>\n<p>Ce ne sont l\u00e0 que quelques exemples simples, bas\u00e9s sur nos pr\u00e9c\u00e9dents posts. Il en existe beaucoup d\u2019autres, et peut-\u00eatre aurons nous l\u2019occasion de les d\u00e9tailler dans le futur.<\/p>\n<p>La dette technique est une mesure int\u00e9ressante qui permet d\u2019objectiver la relation avec vos fournisseurs et les \u00e9quipes de projet. C\u2019est un indicateur d\u2019un ordre de grandeur en mati\u00e8re d\u2019effort pour maintenir la non-qualit\u00e9 \u00e0 un niveau raisonnable.<\/p>\n<p>Par contre, \u00e9vitez de consid\u00e9rer la dette technique comme un co\u00fbt financier r\u00e9el \u00e1 prendre en compte dans vos d\u00e9cisions de projet et d\u2019investissement. C\u2019est un concept de d\u00e9veloppeur pour les d\u00e9veloppeurs, pas pour les marketeux.<\/p>\n","protected":false},"excerpt":{"rendered":"<p>Je dois vous faire un aveu : je me suis toujours m\u00e9fi\u00e9 de la notion de dette technique. Cela m\u2019a toujours paru un concept marketing. C\u2019est comme si vous d\u00e9cidiez d\u2019acheter une voiture, que le vendeur vous remette fi\u00e8rement les cl\u00e9s et ajoute avec un petit sourire : \u00ab vous devez d\u00e9j\u00e0 10 000 $ [&hellip;]<\/p>\n","protected":false},"author":3,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[2],"tags":[],"class_list":["post-152","post","type-post","status-publish","format-standard","hentry","category-qualite-des-applications"],"_links":{"self":[{"href":"http:\/\/qualilogy.com\/fr\/wp-json\/wp\/v2\/posts\/152"}],"collection":[{"href":"http:\/\/qualilogy.com\/fr\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"http:\/\/qualilogy.com\/fr\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"http:\/\/qualilogy.com\/fr\/wp-json\/wp\/v2\/users\/3"}],"replies":[{"embeddable":true,"href":"http:\/\/qualilogy.com\/fr\/wp-json\/wp\/v2\/comments?post=152"}],"version-history":[{"count":2,"href":"http:\/\/qualilogy.com\/fr\/wp-json\/wp\/v2\/posts\/152\/revisions"}],"predecessor-version":[{"id":155,"href":"http:\/\/qualilogy.com\/fr\/wp-json\/wp\/v2\/posts\/152\/revisions\/155"}],"wp:attachment":[{"href":"http:\/\/qualilogy.com\/fr\/wp-json\/wp\/v2\/media?parent=152"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"http:\/\/qualilogy.com\/fr\/wp-json\/wp\/v2\/categories?post=152"},{"taxonomy":"post_tag","embeddable":true,"href":"http:\/\/qualilogy.com\/fr\/wp-json\/wp\/v2\/tags?post=152"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}