Discussion :

[Patrick Ruiz]

Le no-code : futur de la filière programmation ? C'est l'avis du fondateur de Bubble qui explique pourquoi les ingénieurs devraient soutenir les outils no-code
Critiqués sur l’aspect maintenance

Le no-code est-il le futur de la filière programmation de logiciels ? C’est l’avis du fondateur de la startup Bubble spécialisée dans la fourniture d’outils no-code destinés aux professionnels extérieurs à la filière informatique et désireux de concevoir et de créer des applications web. « Le no-code est le futur de la filière programmation parce que les programmeurs sont toujours plus productifs lorsqu'ils travaillent au bon niveau d'abstraction pour le problème qu'ils essaient de résoudre », lance-t-il comme raison pour laquelle les professionnels de la filière doivent soutenir les outils no-code. La question divise néanmoins dans le milieu sur des aspects comme la maintenance des logiciels produits à partir d’outils no-code.

L’intégralité de son positionnement

La plupart des ingénieurs logiciels adorent coder (citation nécessaire), aussi une technologie appelée "no-code" suscite-t-elle généralement et de manière compréhensible un désintérêt ou une aversion.

C'est dommage, car le no-code a le potentiel d'améliorer de façon massive la vie quotidienne des programmeurs. De puissants environnements de développement intégrés (IDE) comme Visual Studio Code accélèrent considérablement la productivité des programmeurs. Ils permettent d'organiser, de vérifier le type et de refactoriser le code et peuvent faire gagner d'innombrables heures de travail. Le no-code va encore plus loin. Au lieu que l'environnement de développement intégré soit construit au-dessus d'un langage existant, l'environnement de développement intégré est le langage.

Le no-code est en fait l'une des choses les plus excitantes de la filière ingénierie en ce moment. Être capable d'assembler une interface utilisateur en quelques minutes sans tâtonner avec les CSS ? C'est merveilleux. Être capable de mettre en place une logique d'entreprise sans se soucier de l'emplacement des données ou de la syntaxe ? Incroyable. Ne plus jamais avoir à écrire de logique CRUD sur plusieurs couches de la pile ? Le paradis.

Étant donné que le terme "no-code" est désormais à la mode et qu'il est utilisé de manière approximative, je vais vous proposer une définition. Le no-code est :

• un langage de programmation ...
• ... couplé à un environnement de développement...
• ... pour offrir un plus haut niveau d’abstraction que la précédente génération de langages de programmation à usage général (Javascript, Python, Ruby, Java, etc.)

Allons maintenant dans le détail de chacune de ces composantes :

Le no-code, c'est de la programmation

On croit souvent à tort que l'absence de code n'implique pas de programmation. Malgré son nom, le no-code ne s'oppose pas à la programmation traditionnelle. Il s'agit plutôt de la continuation naturelle des tendances qui ont débuté avec l'invention du FORTRAN dans les années 1950.

Les outils no-code sont souvent confondus avec les créateurs de sites Web et les systèmes de gestion de contenu tels que SquareSpace ou WordPress, mais ces outils existaient bien avant le no-code. Contrairement à ces outils, les langages sans code modernes tels que Bubble sont complets au sens de Turing et nécessitent le même type de logique de programmation que le codage. Programmation (communication précise de la logique à un ordinateur) <> code (communication précise et textuelle de la logique à un ordinateur).

Le no-code fusionne le langage avec l'IDE

Les IDE analysent le code en arbres syntaxiques abstraits qui sont la forme logique réelle du langage. Les IDE sans code sautent l'étape d'analyse et permettent de modifier directement l'arbre syntaxique abstrait. L'interface utilisateur de l'IDE devient la représentation canonique du programme.

Lorsque vous faites de la représentation canonique d'un programme l'interface utilisateur de l'EDI plutôt qu'un fichier texte, cela ouvre de nouvelles possibilités. Votre EDI peut rendre chaque partie du programme de la manière la plus naturelle possible. Par exemple, les sites Web et les applications peuvent être rendus et modifiés visuellement. Vous pouvez commencer à vous poser la question suivante : quelle est la meilleure expérience utilisateur pour cette fonctionnalité particulière du langage ?

Le no-code offre un plus haut niveau d'abstraction

La progression naturelle de la programmation est passée des langages de bas niveau, qui offrent un accès brut au matériel informatique sous-jacent, aux langages de plus haut niveau, qui font abstraction des détails qui ne sont pas essentiels à l'intention du programmeur. Le langage assembleur, dans lequel il faut comprendre les subtilités de la conception des puces, se situe au bas de l'échelle. Les langages à ramassage d'ordures, comme Python ou Java, se trouvent tout en haut : en travaillant en Python, vous n'avez pas à penser à l'allocation et à la désallocation de la mémoire comme vous le faites en C.

Avant l'avènement du no-code, la progression de la couche d'abstraction des principaux langages de programmation était au point mort. Au lieu de cela, les programmeurs utilisaient des cadres spécifiques à un domaine au-dessus des langages généraux pour obtenir des gains de productivité. Dans le domaine du développement web et mobile, la montée en puissance de React sur le front-end et de frameworks comme Express sur le back-end ont constitué les prochaines frontières de l'abstraction.

Cependant, la programmation dans un framework web "moderne" reste incroyablement complexe par rapport à la simplicité de ce que vous essayez réellement d'exprimer, qui est généralement une interface utilisateur, une certaine logique métier, des requêtes backend et une connectivité avec d'autres services. Entre autres choses, vous devez vous préoccuper :

• des subtilités de HTML + CSS et comment elles diffèrent selon les navigateurs ;
• de la communication navigateur ←→ serveur : quelles données vivent où, combien de temps il faut pour que les données passent du backend au frontend, et les protocoles utilisés pour transmettre les données (websockets, http, JSON, etc) ;
• des schémas de base de données, migrations, indexation et performances ;
• de l'hébergement et des DevOps.

Lorsque vous créez des applications dans un langage conventionnel, vous vous retrouvez à faire la même chose encore et encore : créer des formulaires d'inscription et de connexion, écrire la logique de validation de l'interface utilisateur, mettre en place l'hébergement et les pipelines CI/CD, écrire le modèle ORM, exécuter les migrations de base de données et des centaines d'autres tâches qui ont été faites encore et encore par des programmeurs précédents.

Les langages no-code font abstraction de tout cela. Étant donné que les IDE no-code sont totalement libres de représenter les concepts de la manière la plus facile à utiliser, ils sont parfaits pour les langages spécifiques à un domaine : le langage lui-même peut être adapté à chaque domaine problématique que vous souhaitez aborder.

La contrepartie de cet avantage est la généralité. Les langages sans code ne sont pas aussi polyvalents qu'un langage comme Python, mais pour la grande majorité des projets, c'est un bon compromis. La plupart des travaux de programmation se déroulent dans un domaine bien défini, comme le développement Web, alors pourquoi ne pas utiliser un langage spécialisé à cet effet ?

Parfois, lorsque vous travaillez dans un langage de plus haut niveau comme Python, vous avez besoin de descendre à un langage de plus bas niveau comme le C. Vous devez peut-être écrire une logique critique en termes de performances qui bénéficie du contrôle d'exécution détaillé que le C vous offre par rapport à Python. Python résout ce problème en vous permettant d'envelopper du code C dans une fonction Python.

De même, les langages sans code vous permettent de vous rabattre sur des langages à usage général lorsque cela est nécessaire. (Les langages construits en partant du principe que vous ferez souvent cela sont souvent appelés "low-code"). Par exemple, dans Bubble, vous pouvez écrire de nouveaux composants en Javascript qui se comportent alors comme des composants natifs de Bubble. Les langages sans code interagissent souvent avec les langages traditionnels via des API : Bubble vous permet de publier une API à partir de votre application et de vous connecter à des API créées dans d'autres langages.

Les points qui fâchent avec le no-code, d’après l’architecte logiciel Hosk

Le cauchemar de la maintenance des logiciels low-code

Selon Hosk :

• la création d'un logiciel est rapide, mais la maintenance dure des années et est plus coûteuse ;
• Les logiciels créés par des développeurs citoyens vont créer une dette technique à grande échelle ;
• la création de nombreuses petites applications va créer un cauchemar de maintenance au sein de la filière informatique ;
• les frais généraux de maintenance ne cesseraient d'augmenter : « C'est comme si vous deviez maintenir des centaines de feuilles de calcul Excel avec des formules, un mauvais nommage, aucune cohérence et peu de documentation » ;
• les outils de développement low-code devraient être maintenus par des personnes compétentes en matière de low-code, qui se spécialiseraient dans ces compétences. Les équipes informatiques devraient se perfectionner dans les outils de développement low-code, ce qui augmenterait les coûts.

Les logiciels low-code ne peuvent pas gérer la complexité

Hosk estime que les outils de développement low-code sont excellents pour créer de petites applications indépendantes, mais ils ont du mal à répondre aux exigences complexes : « À moins que le monde ne s'oriente vers des exigences simples, les logiciels low-code ne remplaceront pas 80 % de tous les logiciels créés. Le pouvoir du code est de créer des logiciels complexes conçus pour fonctionner exactement comme les entreprises et les systèmes le souhaitent. Il sera donc difficile de créer des logiciels complexes avec de nombreux développeurs travaillant en même temps avec des outils low-code. »

Les problèmes de sécurité et de données liés au low-code

Hosk est d’avis que pendant que les services informatiques se familiarisent avec les nouveaux outils low-code, il y aura des violations majeures de la sécurité parce que personne n'a compris comment verrouiller les outils de développement low-code. En sus, il faut du temps pour comprendre les nouveaux outils et créer les meilleures pratiques pour s'assurer qu'il n'y a pas de failles de sécurité ou de problèmes de données. La puissance des outils low-code serait que vous pouvez vous connecter aux médias sociaux comme Twitter, Facebook et d'autres systèmes et les données de l'entreprise peuvent se retrouver sur Internet.

Le low-code et le battage médiatique

Hosk entrevoit une explosion de la création d'applications low-code, mais aussi une augmentation de la demande de professionnels pour les besoins en maintenance et formation. Le développement low-code ne signera-t-il pas la fin des développeurs ou du code selon ce schéma : augmentation de la popularité, création de nombreux logiciels low-code ; problèmes de maintenance des logiciels low-code ; les développeurs créeront des centres d'excellence et guideront les développeurs citoyens vers les meilleures pratiques ;
le low-code sera utilisé pour de petites applications, pas pour tout le développement de logiciels exigeants.

L'avenir du développement d'applications est hybride

Selon Hosk, les compétences des développeurs ne se limitent pas à l'écriture du code. Les développeurs sont des professionnels ayant des années d'expérience et de bonnes pratiques conçues pour créer des logiciels faciles à maintenir. Par contre, les développeurs citoyens et les équipes informatiques devraient constater que les logiciels low-code créés par des développeurs citoyens seront difficiles à prendre en charge, à maintenir et à étendre. C'est la raison, selon l’architecte logiciel, pour laquelle la révision du code par des développeurs expérimentés existe. Cela empêche la création de code de mauvaise qualité :

« Vous pouvez donner des outils de bricolage aux gens, mais cela ne fait pas d'eux des experts en bricolage, comme le montrent de nombreuses améliorations de la maison. Les améliorations apportées à la maison par des développeurs citoyens fonctionnent à court terme, mais il s'agit de lacunes à court terme qui finissent par être corrigées. »

Enfin, Hosk pense que les développeurs de logiciels ne seront pas remplacés, mais ils devraient être recyclés pour utiliser des outils low-code pour créer des logiciels : « Pour que les outils low-code soient efficaces, ils devront être créés en utilisant les meilleures pratiques, le déploiement, les revues de code et d'autres activités des développeurs professionnels. Le développement de logiciels low-code continuera à se développer, mais les exigences complexes et les grands systèmes dépasseront les capacités des outils low-code. À l'avenir, les outils de développement low-code créeront jusqu'à 50 % des applications et les solutions seront un mélange de low-code et de code. »

Sources : Bubble, Hosk

Et vous ?

Que pensez-vous des outils no-code et low code ? Lequel de ces avis colle le plus avec le futur de la filière programmation que vous entrevoyez en lien avec ces outils ?
Partagez-vous l’avis selon lequel l’avenir de la filière développement de logiciels est hybride ?

Voir aussi :

80 % des technologies pourraient être créées par des professionnels extérieurs à l'informatique d'ici 2024, grâce aux outils low-code, selon Gartner

Forrester : l'utilisation des plateformes de développement low-code gagne du terrain dans les processus de transformation numérique des entreprises

Le marché mondial des technologies de développement low-code va augmenter de 23 % en 2021, selon les prévisions de Gartner

Microsoft lance Power Fx, un nouveau langage de programmation low-code open source basé sur Excel

[yahiko]

Pour le prototypage, les outils low-code sont une très bonne approche.

Les outils low-code permettront aussi de davantage démocratiser la programmation. Ca c'est une certitude aussi.

Mais comme construire une centrale nucléaire avec des kits Ikea, ce qui n'est ni faisable, ni souhaitable, il en va de même dans le logiciel.
On aura toujours besoin d'approches high-code pour embrasser la complexité d'un sujet et développer des applications robustes et pérennes.

[MacaronFR]

Je suis aujourd'hui employé dans une startup qui compte sur un certain nombre d'outils no-code/low-code pour son succès
A force de les utiliser j'ai donc fini par en retenir des avantages et inconvénients redondant.
Premièrement, les outils no-code on l'avantage d'être accessible par des personne peu ou pas initié à l'informatique ce qui permet de déléguer des tâches ne concernant pas l'écriture de code à d'autre personne que des programmeur et donc de leur laisser la possibilité de se consacrer à des tâches plus en rapport avec leur compétence.
Malheureusement la plupart du temps, ces outils ne sont pas complètement adapté à la situation demandé et doivent être utilisé aux dépends de la volonté première d'utilisation.
Alors on cherche de meilleurs alternatives ou des moyens de tout de même faire ce que l'on veut et cela a un cout notamment sur les performances. En effet certain outils vont devenir laborieux à utiliser au fur et à mesure de l'alourdissement de l'application, et d'autre vont aussi ralentir (et donc détériorer) l'expérience utilisateur, ce qui ne peut pas être accepter.
Je pense effectivement que les outils no-code ont un devenir important dans le monde informatique mais que leur meilleurs version serait des outils interne pour automatiser certaine tâche de manière accessible à des personne étrangères au monde de la programmation.

[AoCannaille]

##########################

[kbadache]

Pour que les outils no-code marchent, ils faudraient qu'ils aient toutes les règles de gestion possible et imaginable pour chaque métier possible et imaginable, existant et à venir, sinon ceux sont juste des outils pour faire des sites web.
Spoiler, ça existe déjà avec Wordpress.

[totozor]

De mon point de vue de non développeur voici deux scénarios d'appli no-code "bien gérées":
Un gars développe un outil qui répond à un besoin au périmètre bien définit (j'avais dit "bien géré")
Il arrive à un truc cool
Scénario 1:
Son voisin qui fait la même chose demande s'il peut aussi s'en servir
Finalement son voisin ne fait pas exactement la même chose, donc ils adaptent l'appli
L'appli s'étend jusqu'au moment où elle ne convient plus à personne mais que c'est mieux que rien
Le gars au début se retrouve avec une appli qui le dépasse (je vous rappelle qu'il n'est pas dev)
L'appli est utilisée, elle ne fait pas ce que veulent les gens mais ils ne s'en rendent même pas compte.

Scénario 2:
Il manque une fonctionnalité à son appli, il rajoute une couche
Il manque une fonctionnalité à son appli, il rajoute une couche
Il manque une fonctionnalité à son appli, il rajoute une couche
La nouvelle couche fait bugger une précédente mais il ne sait pas pourquoi.
Il essaye de revenir en arrière mais a mal/pas gérer ses versions
Il jette l'éponge

Ces deux histoires résument une grande partie de ma carrière il faut juste remplacer no code par VBA.

Fut une époque ou je définissais le périmètre clairement avec le client en insistant qu'on ne saurait pas en sortir.
Ils sont toujours OK au début.
Ils demandent TOUJOURS d'en sortir au bout de 6 mois/1 an.

J'ai arrêté le frais depuis quelques années mais on vient encore me voir quand quelqu'un arrive à la fin de l'un des scénario.

NE DONNEZ PAS DE NO CODE A DES NON DEV, 99.9% d'entre eux en feront de la merde en se prenant pour des génies.

[mermich]

2 experiences perso, c'est hautement significatif....

bon plus serieusement, le no-code n'est pas une solution valable a long terme, par contre le low code peut apporter pas mal de solutions pertinentes pour petites et moyennes structures.
Le truc est sans doute trop hypee, mais peut si bien utilise remplir pas mal de besoins.

[el_slapper]

J'ai pas bien compris si c'était juste du code avec un plus haut niveau d'abstraction, ou si c'est un énième générateur de code. Evidemment, je suis favorable au premier. Les détails techniques ne sont pas forcément pertinents, et j'aime quand je peux m'en affranchir. Par contre, il faut pouvoir être flexible sur la logique métier, et intelligent sur l'industrialisation du code.

Puisqu'on a cité le VBA, ma première refonte (pas bien dure, vous allez voir, c'est pas du niveau de John Carmack) partait d'un code du type :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
For I = 1 To 2
    (traitement des lignes 1 et 2 qui sont en alpha)
Next
For I = 3 To 5
    (traitement des lignes 3 à 5 qui sont décimales)
Next
For I = 6 To 7
    (pareil que les lignes 1 et 2)
Next

Et il y en avait sur 120 lignes. J'en ai profité pour corriger deux ou trois bugs (c'était même pas du copier coller, tout avait été fait à la main). Et quand je suis parti, les gens pouvaient ajouter ou retirer des lignes en dynamique, la macro VBA s'adaptait toute seule.

4 ans plus tard, je suis retombé dessus ça ne ressemblait plus à rien, plus personne n'arrivait à en tirer quoi que ce soit, j'ai refait un truc propre et surtout simple (qui a sans doute subi le même sort).

En fait le VBA, c'est un vrai langage de programmation. On peut parfaitement faire des trucs propres et industrialisés avec (même si il manque un ou deux trucs bien pratiques des langages modernes). Mais il faut avoir la culture qui va bien. Et ces outils low code, j'ai l'impression que c'est pareil. Et le vrai problème de VBA, c'est que la plupart du temps, on met ça dans les mains de gens qui n'ont pas la culture, et à qui on ne prendra pas le temps de l'apprendre. Je vois le même destin pour le low-code. Alors que c'est sans doute très bien, à la base.

[thamn]

Au fond, en tant que programmeur, si le "no-code" me permet de pas avoir a entendre parler des projets boiteux qui devrait même pas avoir été pensé, c'est vraiment pas si mal. Si quelqu'un est pret a payer je ne sais qui pour ne pas coder son application, j'aime autant ne jamais avoir a le rencontrer.

[totozor]

2 expériences perso, c'est hautement significatif....

C'est vrai que deux expériences ne sont pas significatives mais je parle en fait de dizaines de "projets" qui ont tous suivis ces deux modèles.
Et dans une bonne partie des cas j'étais le prétentieux qui se prenait pour un développeur parce que j'avais fait une macro VBA capable d'importer des données, de calculer 2 colonnes et de mettre des cellules en couleur.
On vient me voir pour faire refonctionner un fichier Excel qui bug environ tous les deux mois. En général la personne ne sait pas comment le fichier devrait fonctionner, ne sait pas qui a conçu ce fichier et ne se rend même pas compte qu'il donne des informations erronées depuis longtemps.

Je trouve (et je me trompe peut etre) que ces fichiers ressemblent, dans le concept, à ce que vendent les outils no/low code.
Les entreprises semblent vouloir se débarrasser des macro VBA, ce qui est une bonne chose de mon point de vue. Mais les remplacer par autre chose qui vend les même rêves (permettre à chacun de concevoir un outil facile, puissant, pérenne avec un périmètre ultra large) n'a pas de sens.

[el_slapper]

Je trouve (et je me trompe peut etre) que ces fichiers ressemblent, dans le concept, à ce que vendent les outils no/low code.
Les entreprises semblent vouloir se débarrasser des macro VBA, ce qui est une bonne chose de mon point de vue. Mais les remplacer par autre chose qui vend les même rêves (permettre à chacun de concevoir un outil facile, puissant, pérenne avec un périmètre ultra large) n'a pas de sens.

ça dépend, tu parles de fichiers avec des formules, ou avec des macros VBA? Dans le premier cas, oui, on est sur du no-code des années 1990 (qui marche bien, d'ailleurs, tant qu'on reste raisonnable dans ce qu'on lui demande). Dans le deuxième cas, techniquement, non, VBA est tout sauf du no-code. Mais sociologiquement, oui - on demande à des non-codeurs de faire du code, ou de produire des résultats s'apparentant à ce qu'on peut faire avec du code. C'est similaire en termes de perception.

Je pense que le point important est "tant qu'on reste raisonnable dans ce qu'on demande". Un para-programmeur peut obtenir des trucs honnêtes si il ne se prend pas pour un cador, et reste sur des choses simples Le mensonge, c'est de croire qu'il aura un truc professionnel et industrialisé juste en reliant trois boites, ou en faisant trois copier-coller.

[Mat.M]

Que pensez-vous des outils no-code et low code

les outils no-code et low code ont été inventés dans une optique majeure de produire des lignes limitées de code évidemment.

Pourquoi écrire un nombre limité de lignes de code ? Pour la bonne et simple raison que sur un projet informatique la ligne de code a un certain coût financier en corrélation avec le taux horaire auquel est payé le programmeur.
Mettons qu’un programmeur français tape 50 lignes de code en une heure il est payé 50 euros HT l'heure ça fait 1 euro la ligne de code.
Les américains ils pensent comme ça

Plus un projet info a des lignes de code plus ça coûte financièrement parlant à faire évoluer et à maintenir.
Le low-code et no-code permettent les économies d'échelles et l'industrialisation et augmenter la productivité horaire.

Le revers de la médaille de ces 2 approches c'est de produire du code pas assez optimisé.

[AoCannaille]

Mettons qu’un programmeur français tape 50 lignes de code en une heure il est payé 50 euros HT l'heure ça fait 1 euro la ligne de code.
Les américains ils pensent comme ça.

On peut reprocher plein de choses aux américains, mais concernant la rémunération des développeur, elle est plus proportionnelle aux profits envisagés par l'application que sur le nombre de ligne de code. On arrive a des situations qui devraient être banales : les développeurs, productifs, gagnent plus que les chefs de projet partiellement considérés comme des fonctions auxiliaires au même titre que les RH ou les assistantes de direction...

[Mat.M]

On arrive a des situations qui devraient être banales : les développeurs, productifs, gagnent plus que les chefs de projet partiellement considérés comme des fonctions auxiliaires au même titre que les RH ou les assistantes de direction...

tiens c'est curieux on a la même intuition donc ?
Là dessus je suis à 100% d'accord ce genre de chose il faut le dire aux directions des ESN ou entreprises françaises qui préfèrent embaucher des cadres intermédiaires plutôt que des développeurs productifs.
C'est un truc que j'ai dénoncé maintes fois sur ce forum , le fait qu'il y ait plus de barreurs que de rameurs en entreprise en France
Mais on risque de dévier du sujet principal

[Invité]

chefs de projet partiellement considérés comme des fonctions auxiliaires au même titre que les RH ou les assistantes de direction.

Je me permets une digression par rapport au sujet principal, sur le point que tu soulèves et qui selon moi mérite réflexion :

Dans une startup à la rigueur, ou ce métier peut être dilué entre les différents dev, notamment car largement moins complexe au vu du nombre de personnes et généralement de la difficulté des projets en comparaison d'une entreprise de taille moyenne ou de grande taille.

Dans tous les cas, on ne peut tout simplement pas considérer un chef de projet comme une fonction auxiliaire.
Il faut dissocier le travail de développeur dans une petite entité qui va pouvoir s'occuper de tout (jusqu'à une certaine limite technique et temporelle) et un développeur qui travail sur un gros projet, qui demande donc beaucoup de gens, mais surtout, beaucoup de spécialité (parfois purement scientifiques, parfois purement techniques, ...).

A un tel niveau, il est tout simplement impossible de se passer d'un chef de projet.
Un chef de projet n'est en rien un RH ou une fonction auxiliaire, c'est la clé de voute du projet.
Sans lui, pas de coordination, pas de gestion (financière, d'équipes, ...) et derrière le mot gestion, il y a en réalité non pas une gestion humaine avant tout, mais bel et bien une gestion technique.

Et donc, cette appellation de Chef de projet n'est avant tout rien d'autre qu'un marqueur pour savoir qui s'occupe de la gestion. Selon la taille de l'équipe, ce rôle ce nomme différemment bien que le fond reste le même.

Pour avoir testé un peu de tout, je sais qu'il n'est aucunement pertinent de penser qu'une équipe peut en réalité s'autogérée, en même temps qu'elle doit gérée son client, ses process de dev, sa stack technique, ...

Ça, ça marche, dans de très rares cas où tu es face à de vrais devs chevronnés qui ont plus de 15 ans d'expériences (de vraies expériences, pas de types qui prétendent être senior alors qu'ils n'ont touché qu'à la même techno toute leur vie au travers d'une ou deux boites, qui ne les ont jamais challengées intellectuellement et qui ont malgré tout la prétention de se prendre pour ce qu'ils ne sont pas), et encore, dans ces rares cas, à un moment donné il faut bien arriver à se caler pour gérer le projet.

Tout ça pour dire que, le low code, ou tout outils d'automatisation, ne remplacera en réalité jamais un chef de projet, tout comme il ne remplacera pas non plus en réalité un développeur.

Maintenant, si le sujet est de dire "Ca évitera de prendre des chefs de projet qui ne servent à rien", je suis d'accord et c'est autant vrai que les développeurs qui ne servent à rien.
Mais ça, ce n'est pas non plus le lowcode ou dit autrement, l'automatisation à outrance, qui va changer la donne, c'est la pertinence des choix de ceux qui prennent les décisions.

[edrobal]

Ces deux histoires résument une grande partie de ma carrière il faut juste remplacer no code par VBA.

Fut une époque ou je définissais le périmètre clairement avec le client en insistant qu'on ne saurait pas en sortir.
Ils sont toujours OK au début.
Ils demandent TOUJOURS d'en sortir au bout de 6 mois/1 an.

J'ai arrêté le frais depuis quelques années mais on vient encore me voir quand quelqu'un arrive à la fin de l'un des scénario.

NE DONNEZ PAS DE NO CODE A DES NON DEV, 99.9% d'entre eux en feront de la merde en se prenant pour des génies.

Ce qui n'est pas compris, c'est que programmer ce n'est pas pisser du code. C'est analyser un problème pour en tirer une solution et la coder. Avant VBA, au début de la micro informatique, il y a déjà eu des langages prétendument pour non informaticien comme BASIC, Dbase... Ceux qui ont connu cette époque se souviennent de la daube que les non dev en sortaient.

[nhugodot]

C'est vrai qu'Excel est le code le plus utilisé du monde, in fine:
Excel est le meilleur exemple: à l'inverse du code, on "voit" (le résultat) d'abord au-dessus, on "code" dessous:
Martin Flower (excellent blog très complet!):
https://martinfowler.com/bliki/Illus...ogramming.html

“Most programmers don't think of spreadsheets as a programming environment.
Yet many lay programmers create sophisticated systems using them.
Spreadsheets are a fascinating programming environment that suggest characteristics for a lay programming tool might need:
Immediate feedback - including showing the results of example calculations right away.
Deep integration of tool and language
No textual source
No need to show all information all the time - formulae are only visible when you edit the cell containing them, otherwise the value is shown.”

On parle de no ou low-code depuis toujours, et même l'inventeur de Excel, Charles Simonyi, a travaillé sur de nouveaux paradigmes et outils chez Microsoft pour révolutionner la programmation:
https://en.wikipedia.org/wiki/Intentional_programming
Le créateur de Smalltalk aussi, Alan Kay, juge qu'on attend encore la même révolution software qu'on l'a eu du hardware (et qu'on code toujours comme des cochons...): Smalltalk était (et reste, avec Pharo et ses outils tels que Feenk, Glamorous Toolkit, etc.) bien plus qu'un simple langage, comme dit le créateur de Bubble, mais un IDE tout-en-un, totalement intégré, quasi une machine virtuelle où on touche le code vivant ("live coding"). Magique.

Le résultat de ces "IDE-Langages"? Une productivité énorme, très loin devant Python, JS etc.:
http://www.ifpug.org/wp-content/uplo...pers-Jones.pdf
Soit, codage et activités de non codage (tests etc.) tout compris:
Le même programme en JS est 15% plus long à faire qu’en PHP ou Python, 26% qu’en Dart, et 2,13x plus long qu’en Smalltalk!
Environ 4000 heures en IntegraNova ou Excel, 6900 en Smalltalk, 10 000 en Elixir, 11 000 en Ruby, 11 600h en Dart, 12 700 en Python ou PHP, 14 600 en JS

Quand je vois l'énorme, le gigantesque gâchis de temps (donc de coût) passé par les devs à réinventer la roue telle que les écrans de login/mdp/mdp perdu/profil/etc., j'en suis écoeuré... Et ce n'est ni React ni Flutter ou autre qui ne me sauvent en me proposant ces étapes toutes faites, sauf bricolage (npm, etc.), de génies mais bricolages néanmoins... (même IP et le Web sont des bricolages pas finis, cela dit... même leurs fondateurs le disent, de Louis Pouzin à Tim Bernes-Lee et son initiative SOLID).

Alors oui, le no ou low-code sera une panacée pour nous, demandeurs, chefs de projets, clients, investisseurs, bidouilleurs, et même développeurs qui ne pensent pas à absolument tout maitriser tel qu'il le pense lui-même au boulon près.

C'est bien d'ailleurs le sens de l'Histoire depuis l'électronique, les jumpers, l'Assembleur, le C, Smalltalk et Java (et sa VM), et maintenant les frameworks (de base tel que React, ou complets tel que Angular), voire des "CMF" (Content Management Framework) tel que Drupal (codé sur Symfony), assez flexible pour quasi tout faire en s'appuyant sur une architecture et des modules très riches, matures, solides, flexibles.
Evidemment, plus on abstrait, moins on a la main dessous, ce qui frustre le développeur, artisan qui aime et veut maitriser tout. Mais le client se contrefout de ça, il veut que ça marche, vite, bien, et pas cher. Pas que le bouton soit encore plus beau que l'autre développeur.
Et évidemment à l'inverse, s'il manque une fonctionnalité, pire encore dans le coeur de cette pyramide, alors là oui, il faudra toucher au code, profond, qui impacte peut-être tout ce qui est au-dessus et à côté. Mais là, cela veut peut-être dire qu'on s'est trompé de stack, ou qu'on doit plutôt la demander aux créateurs/mainteneurs de cette stack, pas la modifier soi-même, avec tous les risques que cela comporte! (React -qui le permet car "framework" lâche, doit son succès à cela dans les agences et start-ups où le détail différent des autres compte, versus Angular, plus contraint et donc plus adopté justement par les grandes entreprises pour des usages internes qui se fichent de la couleur du bouton...).

Comme tout, la solution idéale est un juste milieu difficile à trouver... et aucune réponse n'est universelle, mais chacune a son audience.

Excel, VBA, ... on attendait leur pensant "web" (Bubble?) et "mobile" (GoodBarber?) pour enfin redonner la main aux usagers, pour bricoler, pas faire des fondations... Le succès de Notion, Coda, Slite, Fibery (magique!), et toute cette nouvelle génération de no-code web, wikis à tout faire, est la réponse. Merci.

[AoCannaille]

A un tel niveau, il est tout simplement impossible de se passer d'un chef de projet.
Un chef de projet n'est en rien un RH ou une fonction auxiliaire, c'est la clé de voute du projet.
Sans lui, pas de coordination, pas de gestion (financière, d'équipes, ...) et derrière le mot gestion, il y a en réalité non pas une gestion humaine avant tout, mais bel et bien une gestion technique.

Je n'ai jamais remis en question la nécessité d'avoir un chef de projet. Au même titre que je ne remet pas en cause la necessité d'avoir des RH ou des assistantes de direction.
Au même titre que les RH vont être la clef de voute de l'entreprise concernant le maintien des compétences et qu'une bonne assistante de direction simplifie la vie sur tellement de sujets annexe que travailler sans c'est diviser par deux sa productivité.

Une boite sans RH, sans chef de projet, sans assistante de direction, ça marche mal, ça produit mal. Une boite sans dev, ça ne produit rien.

Ce que je souligne donc, ce n'est pas l'inutilité du chef de projet, mais que son utilité est auxiliaire dans le sens premier du terme : aider au développement du projet. Alors que l'utilité du dév est exactement le développement du projet.

Pour filer ta métaphore, on a réussi à construire des bâtiments, et même des solides (Colisée, parténon, pyramides), avant la découverte de la clef de voute, mais aucun sans mur.

L'utilité du chef de projet est donc surestimée, et par voie de conséquence selon moi, qu'ils sont sur-rémunérés.

Cela soulève la question suivante : quand on lit partout qu'il y a pénurie de dev, mais pas pénurie de chef de projet : pourquoi la l'offre et la demande n'inverse pas les salaires?

[edrobal]

Cela soulève la question suivante : quand on lit partout qu'il y a pénurie de dev, mais pas pénurie de chef de projet : pourquoi la l'offre et la demande n'inverse pas les salaires?

Parce que le plus souvent, la rémunération d'une fonction est inversement proportionnelle à son utilité.

[Invité]

Je n'ai jamais remis en question la nécessité d'avoir un chef de projet. Au même titre que je ne remet pas en cause la necessité d'avoir des RH ou des assistantes de direction.
Au même titre que les RH vont être la clef de voute de l'entreprise concernant le maintien des compétences et qu'une bonne assistante de direction simplifie la vie sur tellement de sujets annexe que travailler sans c'est diviser par deux sa productivité.

Une boite sans RH, sans chef de projet, sans assistante de direction, ça marche mal, ça produit mal. Une boite sans dev, ça ne produit rien.

Ce que je souligne donc, ce n'est pas l'inutilité du chef de projet, mais que son utilité est auxiliaire dans le sens premier du terme : aider au développement du projet. Alors que l'utilité du dév est exactement le développement du projet.

Pour filer ta métaphore, on a réussi à construire des bâtiments, et même des solides (Colisée, parténon, pyramides), avant la découverte de la clef de voute, mais aucun sans mur.

L'utilité du chef de projet est donc surestimée, et par voie de conséquence selon moi, qu'ils sont sur-rémunérés.

Cela soulève la question suivante : quand on lit partout qu'il y a pénurie de dev, mais pas pénurie de chef de projet : pourquoi la l'offre et la demande n'inverse pas les salaires?

Hello AoCannaille,
Ne vois aucune agressivité ou tentative d'avoir raison, quoi qu'il en coute dans ma réponse, mais simplement une réflexion par rapport à ce que tu avais initialement posé.

Premièrement, je comprends et je suis d'accord avec la majorité de ce que tu écrits, je suis moi-même ET dev ET chef de projet. Dev depuis pas mal d'années, + de 20 ans en tant que dev et chef de projet depuis + de 8 ans.
À ce titre, c'est en connaissance de cause, tout de moins je l'espère, que j'écris.

Deuxièmement, je te remercie de ta réponse qui m'a permis d'être convaincu de ton raisonnement, à savoir que tu estimes qu'un chef de projet est bel et bien un poste auxiliaire, sur estimé et sur rémunéré de facto.
La définition d'après le dictionnaire du mot Auxiliaire étant d'aider, sans être indispensable, j'en conclut donc que tu considères encore une fois, bel et bien, le chef de projet comme secondaire sur un projet par rapport à un développeur qui lui ne l'est pas et c'est là ou moi, je te dis que tu te trompes.

Il faut avant tout comprendre que ce métier devient indispensable à partir du moment ou on pense le projet d'une part, selon une certaine volumétrie et d'autre part, selon une certaine rentabilité, je m'explique,

Concernant la partie développeur :
A travers ça, de mon point de vue, il est clair qu'un développeur est bien trop mal payé en France et sous-estimé, là-dessus, on est d'accord.
Dans la majorité des cas, ce métier est bien plus dur que n'importe quel métier de l'entreprise et est avant tout, il faut le dire, un métier d'ingénieur.
Selon moi, la raison principale pour laquelle le développeur est sous-estimé est qu'il reste en France, un métier non conventionné, c'est à dire que n'importe qui peut prétendre être développeur, il suffit après tout d'aller lire un tuto pour s'imaginer être capable de programmer.

Et c'est d'ailleurs pour le voir là aussi, en devant faire les tests de recrutement, devenu la majorité des postulants d'une entreprise, des gens qui viennent de formations de 8 mois, à l'arrache, et sont en réalité incapable d'arriver à pondre une ligne de code.
Ca à la rigueur, j'en fais l'impasse, ce métier est un métier en constante évolution, ce n'est pas le langage qui fait la personne mais avant tout sa capacité de compréhension et d'assimilation.

Il y a donc sûrement un problème de validation avant tout, comme tout métier d'ingénieur, de compétences, de capacités de compréhensions, ... AVANT, de pouvoir faire ce métier.
En d'autres termes, il manque une certification officielle à obtenir en France, avant de pouvoir prétendre être développeur, comme tout métier d'ingénieur et là, c'est en tant que chef de projet que j'entends ce son de cloche, c'est-à-dire en tant que celui qui doit au quotidien travailler avec les clients, les directeurs d'entreprises, ...

On peut se féliciter de faire un métier sans diplômes et on peut aussi râler sur la France, pays qui demande des diplômes pour être crédible, mais on voit aussi les conséquences de ne pas en demander et d'un rapport de force qui sera toujours défavorable, même si la personne a passé avec brio les tests techniques et à un panel de compétences long comme son bras, qu'elle qu'en soit l'époque, si un métier ne demande pas de diplôme pour être exercé, notamment par le fait qu'on pourra toujours le dévaluer par rapport aux autres métiers de l'entreprise.

On peut aussi imaginer que demain, le diplôme sera secondaire à tel point que chaque entreprise payera à la louche ses salariés selon qu'elle estime qu'un poste est plus nécessaire qu'un autre. Mais ça, dans la réalité, ce n'est qu'une porte ouverte pour payer n'importe comment n'importe qui et très souvent, dans le mauvais sens du terme.
Il le faut, nous n'avons pas le choix, à un moment donné ordonner les choses à minima, les réguler, ... et donc dire, ce métier en moyenne et à minima, c'est "tant", parce que "cette raison, celle là, ...".
Et pour pouvoir faire ça, il faut pouvoir justifier cette régulation au delà d'estimation à la louche, d'où la nécessité de diplômes, quoi qu'on en dise, quand on pense cela à l'échelle d'un pays.

Concernant la partie chef de projet:
Je m'excuse si tu le prends mal, mais j'ai l'impression qu'en réalité tu connais mal ce métier.
Quand tu écris qu'un chef de projet est un métier sur estimé, il faut déjà savoir de quel métier en tant que chef de projet on parle.

Un chef de projet SI, ne fait pas le même métier qu'un chef de projet Web, qu'un chef de projet Digitale, et j'en passe.
Tout comme un développeur web, ne fait pas le même métier qu'un développeur de jeux vidéo, qu'un développeur système, ...

Un chef de projet SI, va s'occuper littéralement d'absolument tout dans un projet, sauf de le développer, et dire qu'il est inutile, voir secondaire, permet moi de te le dire, est purement et simplement suicidaire.
Il faut à un moment donné une personne pour gérer le budget du projet, pour gérer son prévisionnel, pour gérer son avancement, gérer son équipe, avec ses évolutions, ses analyses de productivité, son bien être, ...
Ce métier n'est pas un travail de commercial et n'est pas non plus un travail de RH.
Il ne suffit pas de développer un projet pour qu'il fonctionne, ça, ça marche comme je le disais dans mon précédent commentaire, quand tu es dans une petite équipe sur un petit projet.

Imagine que demain ta petite équipe doivent réaliser le prochain netflix pour son client.
Netflix, ce n'est pas juste faire des pages qui permettent à des gens de regarder des films, gérer leurs comptes, ... C'est aussi et surtout, tout un pan d'analyse quand à la rétention des utilisateurs, quand à l'utilisation des serveurs (ceux-ci tiennent-ils la charge, les choix technologiques sont-ils finalement les bons, quels choix faire en amont, en aval, ...), le client représentant netflix demande des évolutions, sont elles pertinentes, si oui, comment les intégrer, ... ?

C'est un métier largement plus vaste que gérer une équipe, c'est un métier avant tout d'analyste.
D'où le fait que ton commentaire me surprenne véritablement et le fait que j'ai avant tout l'impression que tu connaisse mal ce métier.

En conclusion:
Je suis d'accord avec toi, à petite échelle, le métier de chef de projet est dispensable, voir, si requis, totalement soluble au sein de l'équipe.
Maintenant quand on parle de projet à forte volumétrie, qui demande beaucoup de dev, qui demande de sérieusement analyser tout ce qu'il se passe, ... clairement, on ne peut tout simplement pas faire sans chef de projet et encore une fois, c'est aussi un dev qui écrit ça, un dev qui il y a quelques années ne pouvait pas voir en pâture les chefs de projets (vieille école), qui se croyait au dessus du lot et venait donner des ordres aux devs.

Le terme chef de projet est un terme en soit peut-être mal nommé, car certes, il s'occupe de l'équipe, mais c'est 10% de son travail, les 90% restants sont de la pure et simple analyse, des statistiques, des maths à outrances, de la communication avec les différentes parties prenantes, ...
Il est avant tout un coordinateur de l'équipe avant d'être un chef, une équipe de dev n'a pas besoin de chef, elle sait très bien ce qu'elle a faire et comment le faire.

Pour autant, j'en termine là-dessus, à forte voir moyenne volumétrie, il est suicidaire de considérer ce métier comme auxiliaire voir dispensable, c'est tout simplement impossible de faire sans et malgré tout, ça reste un métier extrêmement complexe qui titille sans problème la complexité du métier de développeur, sous un autre point de vue.
La notion de salaire d'un chef de projet, quand tu exerces ce métier très honnêtement, est largement justifiée.

Maintenant le vrai problème selon moi n'est pas le salaire du chef de projet, mais du développeur, qui est en moyenne payé 40K en France, alors qu'il en rapporte 3fois plus par projet.
Si pas de dev, comme tu le dis, personne pour réaliser le projet.
Mais de même, si pas de chef de projet, pas de projet, tout court.

Bref, je m'arrête là, ce n'était pas le sujet principal.