IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)

Vous êtes nouveau sur Developpez.com ? Créez votre compte ou connectez-vous afin de pouvoir participer !

Vous devez avoir un compte Developpez.com et être connecté pour pouvoir participer aux discussions.

Vous n'avez pas encore de compte Developpez.com ? Créez-en un en quelques instants, c'est entièrement gratuit !

Si vous disposez déjà d'un compte et qu'il est bien activé, connectez-vous à l'aide du formulaire ci-dessous.

Identifiez-vous
Identifiant
Mot de passe
Mot de passe oublié ?
Créer un compte

L'inscription est gratuite et ne vous prendra que quelques instants !

Je m'inscris !

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 , par Patrick Ruiz

99PARTAGES

13  4 
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

Une erreur dans cette actualité ? Signalez-le nous !

Avatar de AoCannaille
Membre expert https://www.developpez.com
Le 14/03/2022 à 11:26


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

15  0 
Avatar de yahiko
Rédacteur/Modérateur https://www.developpez.com
Le 14/03/2022 à 10:05
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.
13  0 
Avatar de totozor
Membre confirmé https://www.developpez.com
Le 14/03/2022 à 12:21
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.
12  1 
Avatar de el_slapper
Expert éminent sénior https://www.developpez.com
Le 14/03/2022 à 18:17
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
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.
7  1 
Avatar de thamn
Membre actif https://www.developpez.com
Le 15/03/2022 à 2:42
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.
4  0 
Avatar de totozor
Membre confirmé https://www.developpez.com
Le 15/03/2022 à 8:25
Citation Envoyé par mermich Voir le message
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.
4  0 
Avatar de kbadache
Membre actif https://www.developpez.com
Le 14/03/2022 à 11:43
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.
3  0 
Avatar de edrobal
Membre actif https://www.developpez.com
Le 18/03/2022 à 9:44
Citation Envoyé par totozor Voir le message
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.
3  0 
Avatar de AoCannaille
Membre expert https://www.developpez.com
Le 18/03/2022 à 16:36
Citation Envoyé par tanguy_c Voir le message
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é.
Ne t'inquiètes pas pour ça, même si ce n'est pas le cas pour tout le monde, tant qu'un message texte est écrit sans majuscule ou bourrés de points d'exclamations, je le considère cordial, pas aggressif ^^

Citation Envoyé par tanguy_c Voir le message
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.
Yes, bien résumé.

Citation Envoyé par tanguy_c Voir le message
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.
Ta définition m'a étonné car, comme cité précédemment, je ne considère pas les chefs de projets comme inutiles ou dispensables, et "auxiliaire" dans ma bouche (ou sur mon clavier), n'est aucunement diminuant ou péjoratif. J'ai énormément de respect pour tous les métiers qui font passer les autres avant soit. D'autant plus que je n'avais jamais vu cette notion associée à "Auxiliaire".
D'ailleurs, Larousse n'évoque pas cette notion de "sans être indispensable" :
Citation Envoyé par Larousse
https://www.larousse.fr/dictionnaire...uxiliaire/6901
Personne qui apporte sa collaboration, son aide à quelqu'un d'autre dans l'exécution d'un travail
Ce qui correspond pas mal à la défintion que je me fait du chef de projet : Il prémache les décisions pour qu'on ait qu'a avancer sur le fond des problèmes.
à partir de là, une partie de ta démonstration rate un peu sa cible ^^'

Citation Envoyé par tanguy_c Voir le message
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, ...
Certes, une certification au préalable serait utile pour démarrer directement au bon salaire. Mais ça n'excuse pas les patrons de mal payer les devs une fois qu'ils ont démontrés leurs compétences en 2/3 ans.
Car effectivement, on voit vite la différence entre une formation bac+5 pur informatique, celle d'ingénieur généraliste avec une vague surcouche de dev en 5e année, et les reconversions plus ou moins baclées.

Et du coup, on en revient au problème initial: sans rajouter de paperasse, il vaudrait mieux payer les gens à hauteur de leur plu-value sur le projet. Et un dev complet capable de gérer des problématiques de Base de données, Réseau, OSs, Conceptions Objet/Procédurale/fonctionnelle, chaine d'intégration continue et gestion de configuration, ça ne sort pas d'une formation en 8 mois, et ça ne se rémunère pas de la même façon.

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.
Disons que j'en ai croisé quelques uns dans ma douzaine d'année d’expérience. je l'ai même été sur des minis cas (20->50 kloc, 2/3 EQTP)

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.
Du coup, on est pas d'accord, car pour moi même un petit projet il faut quelqu'un pour être chef de projet. Ne serai-ce que pour prendre définitivement les décisions. Effectivement sur les petits projets il est soluble, mais il reste indispensable.

Pour changer d'image, on pousse tous le wagon dans le même sens, mais le chef de projet enlève les cailloux de sur les rails et manipule les aiguillages.
Sans lui le wagon irait moins vite et pas forcément au bon endroit, mais il arriverait. Il vaut bien mieux qu'il soit là, mais c'est pas lui qui fait avancer le wagon!

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.
Exactement, Il libère les devs de faire ces tâches qui ne sont pas de leur métiers.
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.
C'est clair. j'ai travaillé sur un système d'environ 80 Millions de lignes de codes pour une cinquantaine de composants, le mien faisant à la louche 1milion de ligne de code, pour 6/8 EQTP.
Chaque composant avait un CDP évidement, et les composants étaient regroupés plus où moins par fonctions, qui avaient donc chacune un CDP. et évidement, il y avait un CDP tout en haut.

Un chef de projet qui gère des chefs de projets qui gère des chefs de projets. Un rêve pour certain, un cauchemars pour d'autre.
On peut se plaindre du mille feuille, mais je n'ai vu personne pour proposer autre chose...

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.
Tu prêches un convaincu, c'est sûr. De manière générale je préfère gagner plus qu'un chef de projet, mais je ne veux pas baisser leurs salaire.
Le problème est le plafond de verre en France qui fait que pour monter en salaire on doit monter en responsabilité et donc arrêter des développer... En d'autre terme, pour valoriser l’expérience que tu as de ton métier, on te force à changer de métier.
2  0 
Avatar de MacaronFR
Membre à l'essai https://www.developpez.com
Le 14/03/2022 à 10:56
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.
3  2