Discussion :

[X-Girl]

Bonsoir

Je suis tombée sur cette fiche de métier:
https://www.cidj.com/metiers/no-codeur-no-codeuse

Le no code et low code est ce que il y a un marché ? Apparemment ils vont demander 100000 en 2025. Et si j'ai bien compris faut les bases programmation design et ergonomie.

Est ce une vraie opportunité, un nouveau métier ou un effet de mode temporaire ?


Merci pour vos réponses.

[Glutinus]

Les chiffres me semblent dérisoires. Des environnements de développement graphiques, il y en a légion, cela fait belle lurette que ça existe. De toute manière, ça génère du code à la volée et au bout d'un moment il faut relever les manches pour mettre les bras dans le cambouis, donc autant apprendre les bases.

Très honnêtement, cent no-codeurs aujourd'hui, ça me semble peu. Et 100.000 en 2025, ça me paraît illusoire.

[GreatDeveloperOnizuka]

Les outils no-code sont quand même assez avancé maintenant. Perso, bien que dev, j'ai fait la certif no-code de base chez le cloud Azure (power platform) pour le fun et me cultiver il y a 1 an. C'est plutôt sympa et j'ai fait aussi du bubble, c'est vraiment user friendly. Par contre, il faut distinguer le no et low-code.

Avec l'automatisation, tu retrouves aussi ce genre de possibilité même en faisant du dev intégré dans les IDE ou les services style Heroku. C'est donc du low-code car t'as moins à te prendre la tête à implémenter des trucs relous qui reviennent régulièrement style authentification, CI/CD, etc. Le low-code sur Bubble, ça te fourni par exemple une interface où tu vas configurer toi-même tes webhooks.

Les cas d'utilisation que je vois pour le no-code sont les suivants, de là à voir si il y a possibilité de carrière j'en sais rien:
- POC en tant qu'architecte, dev. Genre tu fais rapidement en full no-cde, soit front avec du no-code et le back tu le codes toi-même.
- Créer des outils pour remplacer ta feuille excel. J'ai jamais eu à le faire car j'ai tjr soit trouver un excel qui me faisait le taff sur le net, soit un plugin sur des logiciels SaaS type Notion.

[Bousk]

Ni avenir ni effet de mode imo, juste un atrappe-nigaud, des formations pourries de plus à vendre et un rêve de personnes non tech qui espèrent un jour "se passer des dév et faire eux-même ce qu'ils ont dans leur tête", parce que tout est si simple avec une simple vue d'esprit, pourquoi s'encombrer d'un programmeur à qui il faut (mal) expliquer ce qu'on veut plutôt que le faire soi-même ?
Bref c'est une utopie, dont j'entends parler depuis 20 ans, et qui dure depuis sûrement plus que ça.
Dans le cadre du web en particulier, qui se souvient de dreamwaver etc ? Il y avait une grosse mode des outils WYSIWYG, puis on en est revenus parce que le code généré était tout de même pas ouf, et maintenant la mode c'est les moteurs àla joomla, wordpress, magento etc.
Et ces outils sont vite limités sans un vrai programmeur, qui va aller dans le code source, créer ou modifier des plugins et modules, pour les personnaliser.

[Mat.M]

vite fait bien fait
le low-code/no-code avantages : on peut produire très rapidement un projet c'est très intéressant pour une petite entreprise qui veut un outil de gestion d'entreprise performant et facile à mettre en route sans avoir à investir dans une équipe dédiée de développeurs.

Inconvénient; là où les choses se compliquent c'est lorsque vous avez besoin de développer des fonctionnalités un peu baroques ou trop spécifiques au métier de l'entreprise
Donc au besoin il faut reprendre le code généré et le retravailler.
Je n'y suis pas allé voir dans les détails mais un outil no-code ça doit générer certainement 2 à 3 fois plus de code par derrière que si un développeur créait par lui-même le code...
parce que même si l'outil d'un point de vue marketing est estampillé no-code c'est qu'il faut tout de même générer du code par derrière pour créer une application logicielle.

Bref c'est comme pour une entreprise payer une licence d'ERP: si l'entreprise n'utilise que 5% des fonctionnalités de l'ERP et qu'il faut refaire des paramètrages ça finit par être coûteux en développement pour l'entreprise.
Remarquez ça donne du boulot à des équipes informatiques..

En définitif pour répondre à la question à savoir si cela présente un intérêt de faire une telle formation c'est tout de même conseillé d'apprendre à programmer de manière "traditionnelle" et donc d'apprendre à utiliser un langage informatique lambda comme Javascrip,Php,Java..

pour finir et aller dans le sens du message de Bousk oui ça s'apparente tout de même à du Marketing Multi Level.

[Jean-Philippe André]

Bonjour,

j'apporte un autre son de cloche, plus positif

Plusieurs gros groupes se lancent dans la technologie Power Platform au Canada (mandats anglophones, dans le privé).

Le travail à fournir peut se faire tant au niveau du développement que de l'analyse ou encore de l'architecture solution.

L'expérience comme développement "tradi" permet d'avoir beaucoup plus de facilités pour coder ou débuguer des applications existantes.

Qu'il s'agisse de Power Apps, Power Pages, Power Automate ou Power BI, il y a beaucoup d'opportunités pour se lancer sur la technologie

[el_slapper]

J'ai vu passer ce genre d'outils depuis le début de ma carrière, en 2000. Ca existait déjà bien avant. Je bosse sur un de ces outils, et je veux me casser (bon, en qualité, plus précisément des scripts de tests d'interface graphique, pas en dev applicatif direct, mais la différence est plus maigre qu'il n'y parait au premier abord).

Toujours les mêmes qualités et les mêmes défauts depuis que les japonais (de mémoire) ont lancé le concept dans les années 80

principale qualité : des gens qui font un blocage psychique devant le concept même de code sont parfaitement productifs. Mes deux collègues, en l'occurrence, une est meilleure que moi, et l'autre n'a pas à rougir.

principal défaut : ça scale très mal. Pour disons, 3 personnes toutes à mi-temps sur le sujet comme nous dans la branche française, ça grince, mais ça passe. Pour nos amis américains, qui doivent être plusieurs à temps partiel et pas loin de 30/40 à temps partiel, ça s'effondre déjà sous son propre poids.

Pourquoi? Glutinus donne un début de réponse. Je vais creuser un peu plus.

En fait, quand on code, on architecture un peu (parfois trop, d'ailleurs), et quand ça ne va plus, on réarchitecture. Et c'est assez facile, parce qu'on édite sur un éditeur de texte performant. Dernier truc en date. Je scripte un test de truc comptable. Sur tous les exemples qu'on me donne j'ai deux lignes à la facturation. Bon, je code un "checkpoint" paramétrable et appelable pour vérifier que les valeurs comptables sont bonnes. Avec donc 2 valeurs en paramètres. Systématiquement. Ca marche super. Youpi.

Sauf qu'en creusant et en trouvant de nouveaux cas à couvrir, j'ai trouvé des cas à 3, 4, 5 entrées. Je me retrouve donc avec "Check2lines", "Check3lines", "Check4lines", "Check5lines". C'est moche, hein? Sauf qu'en l'absence de conditions et de boucles, je ne peux pas faire de module générique. Reste la solution "moche" c'est à dire de remplacer tout ça par des tests sur une seule ligne, avec donc jusqu'à 5 par script original (donc de remplacer un appel paramétré par 5...). Avec un éditeur de texte, ça m'aurait pris quelques minutes. Avec l'éditeur graphique, je n'ai pas eu le courage. Donc je reste avec mes 4 procédures de checkpoint toutes moches. Et personne ne va me le reprocher, en plus.

ces outils encouragent une pensée linéaire du produit construit, et découragent les industrialisations intelligentes. Ce n'est pas un problème, encore une fois, si l'appli reste assez petite pour se passer d'industrialisation (ou se contenter d'une semi-industrialisation médiocre). A grande échelle, ce genre de soucis ne pardonne pas. Nos amis américains avaient plus de 80 scripts sur un outils essentiel du bureau du médecin. LE workflow change. Ils ont 80 scripts à refaire un par un, autant dire qu'ils vont tout laisser tomber. Ils auraient en un code, bon, ils en auraient chié quelque jours pour tout réadapter, mais ils n'auraient pas perdu Tout le savoir faire contenu dans les scripts legacy.