Le développement va se simplifier
Tags: developpement, simplification, french, frameworks
Published: 2020-11-14 08:49:11

*Version Française / [English version here](https://dev.to/wanegain3/development-will-become-simpler-o83)*

*Développeur et formateur web depuis une quinzaine d’années, je n’ai pas été épargné par la “Javascript Fatigue”. Ma recherche d’une “cure” à cette fatigue, m’a amené à réfléchir aux absurdités de la programmation, et à l’environnement de programmation idéal.*

*J’aimerais, dans cet article introductif, vous exposer ce dont je suis persuadé : le développement va se simplifier. Par la suite, je préparerais une série d’articles décrivant en détail les raisons de mon opinion. Cela vous permettra je l’espère, d’entrevoir à quoi ressembleront les prochains environnements de développement, ainsi que la programmation web.*

## Mes propos s’inspirent de TRIZ

Imaginer l’avenir, c’est plus facile en se basant sur une méthode. A plusieurs reprise, je ferai référence à **[TRIZ](https://fr.wikipedia.org/wiki/TRIZ)**, une méthode soviétique dont je me suis inspiré, permettant à la fois de résoudre des problèmes d’innovation, et d’innover en prévoyant l’évolution des technologies.

![[Genrikh Saulovich Altshuller](https://matriz.org/about-matriz/about-founder/), inventeur de TRIZ](https://techmeup.org/wp-content/uploads/2020/11/post-2356-5faf8e431ddcd.)

TRIZ à fait ses preuves : à titre d’exemple, [Samsung l’utilise depuis des années](https://www.tdg.ch/economie/entreprises/samsung-veut-exporter-recette-creativite/story/27091885) et elle lui a permit de déposer bon nombre de brevets. Par ailleurs, cette méthode est enseignée dès l’école en Corée du Sud, pays on ne peut plus innovant.

TRIZ comprend de multiples concepts et outils auxquels je ferai référence dans mes articles. Je me réfèrerai principalement aux  [Lois d’évolutions des systèmes techniques](https://fr.wikipedia.org/wiki/TRIZ#Lois_d'%C3%A9volution_des_syst%C3%A8mes_techniques), et au [Diagramme 9 écrans](https://fr.wikipedia.org/wiki/TRIZ#9_%C3%A9crans).

## Le développement va tendre vers un idéal

La première chose à savoir, d’après la *Loi d’évolution N°4 — Accroissement de l’idéalité*, c’est que les outils de programmation, comme tout système, vont tendre vers un idéal. L’idéal, au sens de TRIZ, est définit ainsi :

![Source : [TRIZ for Engineers: Enabling Inventive Problem Solving](https://www.triz.co.uk/structured-innovation), par Karen Gaad](https://techmeup.org/wp-content/uploads/2020/11/post-2356-5faf8e434d06b.png)
>  Un système est idéal s’il offre un maximum de bénéfices, sans coût, et sans effets néfastes.

Cette équation simple remet donc en question une croyance répandue auprès de nombreux développeurs, selon laquelle si les outils actuels permettent de créer des applications plus sûres, plus fiables, plus orientées travail en équipe, plus évolutives, et plus réactives, il *faudrait* absolument les utiliser.

Ce sont en effet de nombreux *bénéfices* qu’apportent les outils et frameworks modernes. Sauf que l’idéal n’est pas atteint pour une raison simple :

## Les outils et frameworks actuels ont un coût et des effets néfastes

![](https://techmeup.org/wp-content/uploads/2020/11/post-2356-5faf8e43b7416.)

Ne le pensez-vous pas ? En voici une liste non-exhaustive :

* **confusion dans les choix techniques** due à la multiplication d’outils concurrents (frameworks, librairies, et outils/modules des environnements)

* **manque de pérennité** des applications, due à ces choix techniques incertains, ainsi qu’aux changements fréquents des syntaxes, et des bonnes pratiques

* **nécessité de posséder de nombreuses connaissances** **et de se former continuellement** afin de maitriser les bonnes pratiques nécessaires à la production d’une application ad-hoc structurée, sécurisée, testée, et optimisée

* **difficulté pour recruter** des profils de développeurs à la fois experts et polyvalents, et **difficulté pour trouver des missions** pour les développeurs non-aguerris aux technos tendances

* **augmentation du temps de production** dus à l’augmentation générale du temps de formation, de paramétrage de l’environnement, du développement, de l’optimisation, des débogages, des tests, des mises en production, etc.

* **augmentation des coûts de production** dû à cette augmentation du temps de production, ainsi qu’à à la rémunération des (rares) développeurs stars maitrisant toutes les techs requises

* **perte d’argent lorsqu’il faut reprendre des applications** à cause des changements fréquents des techs, pratiques, et outils tendances

Cette liste pourrait être allongée et détaillée. Mais il faut simplement retenir que d’après les lois d’évolutions de TRIZ, ces problèmes actuels trouveront une solution.

## Ne faudrait-il pas juste s’(auto-)former ?

Certains d’entre vous pensent peut-être que la solution, c’est de s’y mettre. D’apprendre les dernières syntaxes, patterns, outils, et frameworks actuels. D’autres diront qu’il faut se spécialiser dans l’un de ces outils et d’y passer le temps qu’il faut. Qu’après tout ça fait partie de notre métier, qu’il faut toujours ce mettre à jour, parce que c’est comme ça.

**Mais demander aux développeurs de se former ou de s’auto-former continuellement est sous-optimisé.** Justement parce que la formation représente un *coût* en termes de temps et/ou d’argent. 

Et ce *coût* est non-négligeable, même pour les développeurs confirmés. J’aurai ici voulu pointer sur un article parlant de la **javascript fatigue** mais il y en a trop et je ne peux choisir. Il y a quelque chose dans cette situation qui ne tourne pas rond…

**Ainsi, le *coût* d’attendre des devs qu’ils se forment continuellement réduit l’*idéalité*. Ce n’est pas assez efficace.** En revanche, il y a une autre solution que j’aimerais proposer.

## Simplifions le dev.

![](https://techmeup.org/wp-content/uploads/2020/11/post-2356-5faf8e4461791.)

Il est intéressant de remarquer que **la seule SIMPLIFICATION du développement permet de répondre à chacun des problèmes cités**.

En effet, si les nombreux outils concurrents actuels (frameworks, librairies, bundlers, langages, etc.) ont des niveaux de flexibilité et d’efficacité proches, **le plus simple deviendra le plus populaire, simplement car il est par définition moins *coûteux* en efforts, en temps de formation, en temps de développement et donc en *coût* de production**.

Pendant un temps cette règle n’était pas totalement vraie car les entreprises et développeurs orientaient leur choix vers des outils promus par des références comme Google (Angular) ou Facebook (React). En effet, la popularité des créateurs de ces outils rassurait les entreprises, qui y voyaient en fait les *bénéfices* de la pérennité, de la fiabilité, et de l’optimisation. **Leur complexité représentait certes un investissement (en terme de formation notamment), mais un investissement sûr et conférant de nombreux *bénéfices*.**

Or le scandale du passage d’AngularJS à Angular, ou encore la nouvelle popularité des frameworks “challengers” comme VueJS ou Svelte, montre que **ce critère de popularité est de moins en moins déterminant dans le choix d’une technologie**. Parce qu’on s’est rendus compte qu’**on peut faire aussi bien, en (un peu) plus simple**. 

Ainsi la Simplicité devient petit à petit un critère déterminant car elle augmente l’*idéalité* : **on atteint les même *bénéfices* pour moins de *coûts*.**
>  Simplification 
= moins de temps de formation et moins d’outils concurrents 
= moins de temps de développement et moins de pb dans les choix techs
= moins de coûts de développement, moins de difficultés de recrutement et une meilleure pérennité des applications

Ainsi, il y a tout à parier qu’**à performances similaires, les solutions plus simples remplaceront petit à petit les solutions plus compliquées**. 

## Conclusion

Plutôt que de se former continuellement, il nous faut **changer de paradigme en simplifiant le développement.** Simplifier résout de nombreux problèmes engendrés par les pratiques et habitudes actuelles. 

Toutefois, cette simplification ne sera efficace et utile qu’à condition de conserver flexibilité et performance offertes par les outils actuels.

### Par où commence t’on pour simplifier le dev ?

Dans [Les développeurs n’auront plus à optimiser leurs applications](https://dev.to/wanegain3/les-developpeurs-n-auront-plus-a-optimiser-leurs-applications-56on) je parle de l’Abstraction, qui constitue *un premier moyen* pour simplifier le développement.

Mais cette question mérite d’être abordée plus en détails dans mes prochains articles. Celui-ci se voulait introductif : comme le préconise TRIZ, je souhaitais ici préciser l’objectif à atteindre, en gardant en tête l’idéal.

*Merci de m’avoir lu jusqu’ici.*