Discussion :

[electroremy]

Ça t'arrive des fois de lire une news avant d'écrire totalement n'importe quoi ?

Quelle agressivité

Low code ça n'a rien à voir avec un langage de programmation, c'est du rad visuel.

Je ne suis pas d'accord : ce n'est pas parce que c'est "visuel" que ce n'est pas un langage de programmation.

Dans mon domaine professionnel, en informatique industrielle, certains automates se programment en dessinant un schéma avec des blocs logiques reliés entre eux.
Pour moi, c'est bel et bien de la programmation, même si aucune ligne de code n'est tapée au clavier.

De même, le visual basic permet de concevoir une partie importante du logiciel (toute l'interface, avec un certain nombre de comportements préprogrammés) sans "taper de code", mais ça reste un langage de programmation.

Là ou je te rejoint, c'est que c'est surtout du marketing
Les promoteurs du "low-code" ou du "no-code" font passer une façon différente de saisir du code (dessin au lieu de taper) comme étant une absence de code.

D'ailleurs, les exemples que j'ai donné dans mon premier commentaire, à savoir le fait que les premiers logiciels étaient "câblés" physiquement avec des relais, des tubes ou des transistors, c'est aussi du "rad visuel" mais électrique - c'est long, plus encombrant, plus cher et on se prend des coup de jus

Lorsque, en informatique industrielle ou en électronique, tu réalises un traitement logique avec des circuits intégrés CMOS (portes logiques, compteurs, bascules), hé bien c'est une forme de programmation, en effet, impossible de bien concevoir la carte sans faire de l'algèbre booléenne ou même de dérouler un algorithme (notamment si il y a des compteurs ou des bascules)

Bref, tout ça reste de la programmation au sens large du terme.
D'un point de vue mathématique, que ce soit dessiné à la souris, codé avec un éditeur de texte, câblé physiquement, ou bien construit avec des engrenages, tout ce qui a été dit au sujet des machines de Turing reste valable.

D'ailleurs je me souvient d'une vidéo où des passionnés avaient construit une machine de Turing universelle mécanique avec des Lego Technic.

https://fr.wikipedia.org/wiki/Outils_RAD
https://blog.octo.com/le-low-code-comment-ca-marche/
Le dernier lien donne un exemple intéressant : le tableur Excel.

Même sans avoir recours à VBA, le simple fait de taper des formules revient à coder d'une certaine façon.

La meilleure preuve, c'est que lorsque les utilisateurs d'Excel commencent à faire des choses complexes ils tombent sur des difficultés qui ne peuvent être résolues qu'en comprenant des concepts de base de la programmation informatique. (exemple classique : les références circulaires, qui sont des boucles infinies)

[arnofly]

Bizarre que personne ne parle Wordpress, c'est bien un outil qui a permis à des non développeur de faire de sites Web.
C'est donc effectivement possible.

Ouais... Mc Donald et La Tour d'Argent à Paris sont tous les deux des restaurants. Juste que dans l'un d'entre on y mange de la merde. WordPress, c'est Mc Do. Après que le pro de la souris aura ajouté pleins de plugins pour simuler un semblant de compétences, son usine à gaz aura des perfs pourris et rejoindra le bataillon de tous ces sites de merde qui vident les batteries et font transpirer même des processeurs puissants.

Mais bon, c'est pas cher et WordPress répond à une demande, même si je regrette sa popularité.

[abgech]

J'ai écrit mes premières lignes de Fortran en 1964. Déjà à l'époque certains disaient : "dans quelques années les ordinateurs se programmeront eux-mêmes".

Heureusement qu'il n'en a rien été et que j'ai pu faire une carrière lucrative durant plus de quarante ans.

[oooopppp]

Bonjour,
-> "pour être un développeur de logiciels ni pour créer des applications de types professionnels."
-> remplacer par "professionnelles"

SINON, on trouvé des dev. assez cons pour coder un prog. de codage automatique,
sont'ils suicidaires ou éminemment cons ???

[el_slapper]

SINON, on trouvé des dev. assez cons pour coder un prog. de codage automatique,
sont'ils suicidaires ou éminemment cons ???

Cons? ils vont vendre leur outil comme des petits pains, ils sont loin d'être cons.

[fredinkan]

J'ai beaucoup rigolé quand MS a proposé de remplacer pas mal de process de data via Flow comme outil low code.

Ca marche bien sur des petits trucs... Dans le cas contraire c'est une usine à gaz (qui requiert des compétences de dev, forcément) et qui peut être fait bien plus rapidement via du code ou du scripting... et avec de bien meilleures perfs...

Ca me rappelle la grande époque de VBA qui a créer des usines à gaz non-maintenable...

[el_slapper]

Ca me rappelle la grande époque de VBA qui a créer des usines à gaz non-maintenable...

Le VBA d'ailleurs n'était pas en cause. On peut coder propre en VBA. Il n'a pas toutes les petites astuces des langages modernes, mais permet de faire le boulot. A condition de connaitre son boulot, évidemment, ce qui n'était pas le cas des millions de para-programmeurs qui se sont perdus là-dedans.

1/ Tout part d'un désir de personnes qui ont besoin de solutions informatiques de ne plus dépendre de ... vous. Et oui, vous êtes plus compétents qu'eux, mais ils n'aiment pas devoir passer par vous pour faire les choses. Ces personnes sont prêtes à se contenter d'une qualité moyenne si elles peuvent faire elles-mêmes et la chose fait l'affaire à un coût réduit.

Il y a toujours un calcul de rentabilité à faire. On peut économiser sur la qualité des traductions, au risque de voir les ventes faiblir. Ce n'est pas choquant de voir des gens peser le pour et le contre. Ce qui est choquant, c'est de voir des gens ne peser que le contre, et pas le pour (ou l'inverse, d'ailleurs)

3/ J'ai compris qu'aujourd'hui il reste de nombreux arguments pourquoi les outils low-code ne peuvent faire le boulot correctement. Mais ils sont bien développés par des personnes qui connaissent aussi bien que vous les défis? Qu'est-ce qui leur empêcheraient de trouver de bonnes solutions à cela?

La complexité assez irréductibles des tâches qu'on demande au code de faire. Je sais que je ressort toujours le même vieux lien, mais le code est fait de décisions. Dans le bloc technique qu'on met à disposition de l'utilisateur, on peut mettre toutes les décisions standard qu'on veut. Mais les décisions exotiques, celles qui font la valeur ajoutée de notre boite sur le marché, celles-là ne peuvent pas être livrées en standard. Et elles ne sont pas plus simples que les décisions standard (en moyenne, ça peut varier, hein). Donc même si on encapsule es difficultés techniques (ce qui moi me plait, personnellement), il reste toujours les difficultés fonctionnelles métier. qui, elles aussi, doivent être formalisées de manière propre pour marcher, et pour être maintenables. Et ça, c'est bien le métier du développeur.

4/ Le cauchemar de la maintenance. Pour les incompétents en cette matière, il est évident que ce ne sera pas leur problème de trouver des solutions pour cela. C'est quand-même vous les compétents n'est-ce pas. Je crains que vous allez voir diminuer votre contribution créative et augmenter votre frustration avec les outils qui vous seront imposés par des gens qui n'ont pas les priorités que vous.

Ben, tu viens de résumer 40 ans d'histoire sur le sujet. Pas mal pour quelqu'un qui dit ne rien y connaitre. Sauf que les couts de maintenance sont explosifs comparativement aux couts du projet. Si effectivement on accepte de payer 100 sur 10 ans pour économiser 1 tout de suite, ces outils peuvent avoir du charme. Mais il ne faut pas se voiler la face sur le poids de la dette technique. Et c'est ça que nous dénonçons : les vendeurs de ces produits éludent totalement la question de la maintenance, qui est pourtant vitale pour faire un calcul économique complet.

[Booky McBookerface]

[/INDENT]
Bonjour à tous,

Non, je ne suis pas développeur et vous pouvez dire que je suis incompétente sans rancune, mais j'espère que vous apprécierez tout de même ma contribution à cette discussion, car j'aimerais obtenir vos avis sur quelques pensées qui me sont venues à l'esprit en lisant cet article.

Je ne peux pas me débarrasser de l'impression de déjà-vu en lisant l'article et vos contre-arguments, notamment par rapport au développement des technologies de traduction. Quand j'ai fini mes études en linguistiques (2007), les universités et entreprises commençaient en masse à miser sur la traduction automatique. Bien évidemment, les traducteurs ne voyaient pas non plus comment un processus aussi complexe qu'une traduction pouvaient être faite par un logiciel plutôt qu'un humain ayant fait 4 ans d'études à ce sujet.
En gros, remplacez "informatique" par "traduction" et "low-code" par "machine translation" et ça reste à peu près pareil ;-)

1/ Tout part d'un désir de personnes qui ont besoin de solutions informatiques de ne plus dépendre de ... vous. Et oui, vous êtes plus compétents qu'eux, mais ils n'aiment pas devoir passer par vous pour faire les choses. Ces personnes sont prêtes à se contenter d'une qualité moyenne si elles peuvent faire elles-mêmes et la chose fait l'affaire à un coût réduit.

2/ Non, ça ne gêne pas certains développeurs de développer des produits qui vont bouffer le métier de leurs collègues. Ca ne fait pas d'eux des suicidaires, car ce ne sont pas eux qui seront concernés par d'éventuels pertes d'emploi.

3/ J'ai compris qu'aujourd'hui il reste de nombreux arguments pourquoi les outils low-code ne peuvent faire le boulot correctement. Mais ils sont bien développés par des personnes qui connaissent aussi bien que vous les défis? Qu'est-ce qui leur empêcheraient de trouver de bonnes solutions à cela?

4/ Le cauchemar de la maintenance. Pour les incompétents en cette matière, il est évident que ce ne sera pas leur problème de trouver des solutions pour cela. C'est quand-même vous les compétents n'est-ce pas. Je crains que vous allez voir diminuer votre contribution créative et augmenter votre frustration avec les outils qui vous seront imposés par des gens qui n'ont pas les priorités que vous.

Bon allez j'ai hâte que vous me détruisez pour que je comprenne que j'ai été trop pessimiste ;-)

[jacjac]

Low-Code / No Code
C'est de la trend bullshit commercial digital (celui du milieu levé) pour vendre des formations.

Des gars on voulu faire ça dans les années 90, aujourd'hui on se traine des ESB à la con, des pseudo language de merde (webdev, windev), etc...

[Gilliard]

Et autres langages de spécifications. On nous disait alors (~1980) que bientôt on aurait plus besoin de programmeurs car le code serait directement généré à partir des specs.
Mais en fait, c'est quoi un langage de programmation ? Une autre manière de décrire les spécifications ! Donc le VRAI problème, ce n'est pas de coder, c'est de comprendre et décrire dans un "langage" quel qu'il soit ce qu'on a à faire faire à la machine !

[electroremy]

Le no-code / low-code c'est vraiment du marketing
Comme je l'avais dit plus haut, c'est juste une autre façon de programmer, mais c'est de la programmation quand même

Il y a un autre aspect plus dérangeant : les promoteurs du no-code / low-code ne disent pas que "taper du code" c'est seulement la partie émergée de l'iceberg du développement logiciel.

Pour créer un bon logiciel, quelque soit les outils et la technologie, il faut (liste non exhaustive) :
- prendre le temps d'écouter les différentes catégories d'utilisateur pour comprendre leur besoin - le logiciel doit s'adapter aux utilisateurs et pas l'inverse
- parfois, aider l'utilisateur à formuler son besoin... car les gens ne savent pas toujours ce qu'ils veulent
- lister toutes les contraintes techniques sans en oublier aucune sinon risque d'aboutir à une impasse (format de fichier à utiliser, API tiers à utiliser, compatibilité avec un autre logiciel, système d'exploitation, hardware particulier éventuel, ...)
- élaborer un cahier des charges, définir les fonctionnalités du futur logiciel... et penser aux évolutions ultérieures envisageables
- concevoir la structure de données
- concevoir l'interface (Combien de fenêtres ? Qui serviront à quoi ? Quelle ergonomie ? Saisie graphique à la souris et/ou texte ? Avec quels éléments ? ...)
- concevoir les algorithmes correspondants aux différentes fonctions
- et enfin... coder.

Un logiciel ne se fait pas en tapant directement du code en tapant frénétiquement sur le clavier comme dans les films hollywoodiens
(Sauf pour les petits logiciels vraiment tout simples pour faire une tâche, typiquement un traitement par lot spécifique sur un ensemble de fichiers)

Il y a de nombreuses étapes de conception qui se font en amont, souvent même sans ordinateur, juste avec un crayon et du papier, avec une alternance de moments de réflexion seul et de moments d'échanges en équipe.
Tout le temps "économisé" sur la phase de conception en amont sera perdu en étant multiplié par 100 en phase réalisation
D'ailleurs ça c'est valable aussi en mécanique ou pour les travaux...
J'ai toujours regretté de ne pas avoir assez réfléchi avant de fabriquer quelque chose, mais je n'ai jamais regretté d'avoir passé trop de temps à réfléchir

Le codage, finalement, c'est presque un détail...
Résumer la création d'un logiciel au "code" c'est dénigrer totalement le développement

[Mat.M]

Mais l'introduction du développement low-code/no-code est en train de transformer le développement de logiciels en un processus plus simple avec des délais d'exécution plus courts

je dérive un peu du sujet principal mais si sur une majorité de projets infos il y a de moins en moins de code c'est un gros truc comme G*thub qui risque d'en faire les frais...puisque le principe de ce système est de fournir de l'archivage de code.
et en plus cela a été racheté par Microsoft pour des milliards il n'y a pas longtemps.

[Patrick Ruiz]

Le développement low-code : un mensonge ? Oui, d’après l’architecte logiciel Jay Little
Qui relance le débat sur l’avenir du métier de développeur sous la menace de l'intelligence artificielle

Le low-code est susceptible de remplacer le codage traditionnel d’ici 2024. C’est ce qui ressort d’une étude de Mendix, un éditeur de solutions low-code. Dans les chiffres du sondage, 87 % d’un lot de 556 entreprises répondantes, basées aux USA, au Royaume-Uni, aux Pays-Bas, en France et en Allemagne, envisagent d’accélérer le rythme de leur développement logiciel en s’appuyant sur les outils low-code au cours des deux prochaines années. Les tendances mises en avant viennent raviver le débat sur l’avenir du métier de développeur. En effet, qui dit low-code dit entrée en matière croissante de développeurs citoyens, c’est-à-dire de tiers qui ne sont pas des spécialistes de l’informatique au détriment de ceux qui le sont. Jay Little – architecte logiciel – prend position sur la question et explique pour quelles raisons il est d’avis que le low-code est de la poudre de perlimpinpin.

« J'écris des logiciels personnalisés depuis longtemps et l'une des choses qui m'agacent le plus, c'est lorsqu'un client adopte la position selon laquelle il existe une solution miracle qui réduira ou supprimera la complexité inhérente à cette tâche. Cela arrive plus souvent qu'on ne le pense et devinez quoi ? Ils ont presque toujours tort.

Peut-être suis-je un peu trop vieux et trop lâche pour mon propre bien, mais la vérité est que la création de logiciels pour d'autres personnes est extrêmement difficile. Contrairement à ce que pensent les non-praticiens, cette difficulté n'est pas imputable aux langages, outils et paradigmes de codage. Elle résulte en fait du fait que les clients et les développeurs ne prennent pas le temps de comprendre les causes profondes des problèmes qu'ils veulent résoudre et ne conçoivent pas une solution en fonction des conclusions que vous tireriez de ce processus.

Il ne suffit pas de coder l'outil tel qu'il est spécifié par le client. La première étape avant de commencer à coder est de valider l'existence et les détails du problème lui-même. La plupart des projets de codage sont lancés après que le client s'est rendu compte qu'il avait un problème et qu'il a décidé de demander un code qui, selon lui, le résoudra. En réalité, la plupart des clients ne sont pas des professionnels de la résolution de problèmes, alors que c'est précisément ce que font les développeurs de logiciels. Il nous incombe donc de valider l'approche suggérée par le client avant de lui faire perdre son temps et son argent en la développant », explique-t-il pour souligner que faire du développement informatique ce n’est pas pisser du code.

En gros, le low-code ne saurait faire disparaître les développeurs. Par contre, ce sont des outils qui leur sont destinés afin qu’ils gagnent en productivité. La question de leur adoption divise néanmoins dans le milieu sur des aspects comme la maintenance des logiciels produits à partir d’outils low-code.

Un avis qui rejoint celui de 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.

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.

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. »

Source : Jay Little

Et vous ?

Les chiffres de ce sondage collent-ils avec la réalité dont vous êtes au fait ?
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

[lvr]

Un des gros problèmes que je vois avec les "applications-citoyens", le "low-code", c'est non seulement, les problèmes de maintenance technologique mais aussi toute l'approche gestion et architecture des données.

Que ce soit avec des solutions comme celles de Mendix ou Apps de Microsoft, les "citoyens", "end-users" développent des applications qui gèrent leurs activités dans leur petit coin. Lorsque ces applications introduisent de nouveaux concepts de données et que, dans un autre coin du paysage métier, d'autres utilisateurs se disent que cette information est utile, l'interopérabilité entre les deux coins va être ardue, car l'application qui gère cette information aura été développée uniquement d'un point de vue "end-user" et pas avec des points de vue architecture des données et technique,

Soit parce que les concepts de données n'auront pas été suffisamment rendus génériques et transversaux, soit parce que les plates-formes d'échanges techniques de ces données n'existent pas.

Ces solutions sont dans les moyennes et grosses entreprises, IMO, le retour du fichier Excel et du ré-encodage comme mode d'échange des données entre différentes "applications-citoyens". Avec tous les risques que cela engendre.

Ce qui va sembler être un gain dans l'immédiat (parce qu'on donne aux end-users la possibilité de développer les outils dont ils ont besoin) devient vite un micmac et un danger en termes de pérennisation, de validité et propriété des données ainsi créées.

[totozor]

Un des gros problèmes que je vois avec les "applications-citoyens", le "low-code", c'est non seulement, les problèmes de maintenance technologique mais aussi toute l'approche gestion et architecture des données.
[...]
Ce qui va sembler être un gain dans l'immédiat (parce qu'on donne aux end-users la possibilité de développer les outils dont ils ont besoin) devient vite un micmac et un danger en termes de pérennisation, de validité et propriété des données ainsi créées.

Je suis très d'accord avec toi cependant, dans ma société, on est confronté à trois problèmes :
_ Nos dev sont sous l'eau avec la gestion de nos "gros systèmes" (ERP, PLM etc) donc ils n'ont pas le temps de transmettre leur sagesse aux métiers qui se réfugient dans excel pour répondre à leur besoin.
_ Les métiers ne savent la plupart du temps pas ce qu'ils veulent et nos dev ne savent pas travailler sans cahier des charges.
_ Les métiers qui ont une bonne vision sur leur demande savent ce qu'ils veulent (je veux une machine X développée par chatGPT avec le langage Y et qui compte les cafés dans un camembert bleu) mais ne savent pas exprimer leur besoin (je veux un truc qui fait le café et qui les compte) ce qui mène à une guerre métier/SI chacun remettant en cause son interlocuteur sur le domaine où il n'est pas compétent.

[electroremy]

Tout dépend de ce qu'on appelle "low-code" ou "no-code"

Est-ce qu'un blog créé avec WordPress est du "no-code" ?

Quand je vois qu'on considère un formulaire Microsoft Forms ou Google Forms comme un outil no-code, c'est un peu tiré par les cheveux et ça gonfle les chiffres

A ce moment-là, autant considérer n'importe quel fichier créé par n'importe quel logiciel comme du "no-code"

Ensuite, un langage de programmation graphique où on connecte des blocs logiques, un peu comme en électronique ou électrotechnique (exemple : programmation des automates de sécurité) et bien pour moi c'est du code quand même.

[Jon Shannow]

Tout dépend de ce qu'on appelle "low-code" ou "no-code"

Est-ce qu'un blog créé avec WordPress est du "no-code" ?

Quand je vois qu'on considère un formulaire Microsoft Forms ou Google Forms comme un outil no-code, c'est un peu tiré par les cheveux et ça gonfle les chiffres

A ce moment-là, autant considérer n'importe quel fichier créé par n'importe quel logiciel comme du "no-code"

Ensuite, un langage de programmation graphique où on connecte des blocs logiques, un peu comme en électronique ou électrotechnique (exemple : programmation des automates de sécurité) et bien pour moi c'est du code quand même.

Je pense que la différence se fait dans la manière d'obtenir le code. Soit, c'est une personne (normalement un développeur) qui tape le code, soit, c'est l'outil qui déduit le code d'après les informations transmises par l'utilisateur.
La plupart des IDE ont une partie "no-code". Le développeur dessine la fenêtre, place les différents champs, etc... La "fenêtre/fiche" obtenue (qu'importe le nom que l'IDE lui donne) contient du code que le développeur n'a pas saisi, et qu'il ne modifiera pas (généralement). Certains n'ont même pas conscience de son existence.

[electroremy]

La plupart des IDE ont une partie "no-code". Le développeur dessine la fenêtre, place les différents champs, etc... La "fenêtre/fiche" obtenue (qu'importe le nom que l'IDE lui donne) contient du code que le développeur n'a pas saisi, et qu'il ne modifiera pas (généralement). Certains n'ont même pas conscience de son existence.

C'est une très bonne remarque.

Les IDE Microsoft (VB6, Visual Studio .NET) permettent de dessiner l'interface avec la souris sans taper de code.

Le code généré reste accessible (mais il est déconseillé d'y toucher car cela peut rendre l'édition ultérieure à la souris compliquée)

Après, ce n'est pas vraiment du no-code, mais du code tapé (ou plutôt conçu) à la souris

[HaryRoseAndMac]

Tout dépend de ce qu'on appelle "low-code" ou "no-code"

Est-ce qu'un blog créé avec WordPress est du "no-code" ?

Quand je vois qu'on considère un formulaire Microsoft Forms ou Google Forms comme un outil no-code, c'est un peu tiré par les cheveux et ça gonfle les chiffres

A ce moment-là, autant considérer n'importe quel fichier créé par n'importe quel logiciel comme du "no-code"

Ensuite, un langage de programmation graphique où on connecte des blocs logiques, un peu comme en électronique ou électrotechnique (exemple : programmation des automates de sécurité) et bien pour moi c'est du code quand même.

Eternel débat, le no/low code existe depuis plus de 20 ans et ne fait que muter avec un nouvel élan marketing chaque année.
Wordpress, Joomla, ... c'est clairement ça.

La différence est qu'à mesure ou les choses simples deviennent plus simple, les choses complexes le deviennent tout autant.
Le travail d'un développeur sénior en 2023, est hautement plus difficile intellectuellement qu'il y a 20 ans et pourtant paradoxalement beaucoup plus facile sur le plan de la réalisation.

Aujourd'hui un développeur est appuyé par tout un tas d'outil, des linters et j'en passe, qui font qu'il ne fait quasiment plus d'erreur en codant sur le nommage d'une variable ou autre chose de ce genre à chercher partout pendant des jours d'ou ça vient, par contre, algorithmiquement, mathématiquement et techniquement, le développeur fait des choses largement plus ardus qu'il y a 20 ans.

Certains s'imaginent que coder en assembleur et toute la clique était plus dur que maintenant : faux, c'était un raisonnement à prendre et ensuite ça déroulait tout seul et les problématiques restaient toujours au final simple.

Aujourd'hui le développeur code en PhP, par exemple, qui est hautement plus verbeux, compréhensible, ... mais par contre te code des trucs qui demanderaient aux développeurs de l'époque dont je fait parti de s'arracher intellectuellement les cheveux, voir d'être juste totalement dépassé.

Le monde du dev est et restera un domaine particulier ou au fur et à mesure des années la complexité et la difficulté de la programmation monte en niveau et l'intelligence artificielle n'y changera jamais rien.

Car là, nous parlons clairement du fait d'être dans la créativité pure et dure, et avant qu'une IA ne soit capable d'en faire autant qu'un humain, des voitures volantes seront apparus d'ici là ...

L'IA va clairement rapidement progresser et dans 10 ans ça ne me surprendrais pas que l'on vois des robots humanoïdes aussi réaliste que dans les films de science fiction, mais l'IA est avant tout un mimétisme d'un humain idéalisé, et non pas une conscience à proprement parlé en capacité réelle de faire preuve de créativité au sens premier du terme.

[electroremy]

La différence est qu'à mesure ou les choses simples deviennent plus simple, les choses complexes le deviennent tout autant.
Le travail d'un développeur sénior en 2023, est hautement plus difficile intellectuellement qu'il y a 20 ans et pourtant paradoxalement beaucoup plus facile sur le plan de la réalisation.

Aujourd'hui un développeur est appuyé par tout un tas d'outil, des linters et j'en passe, qui font qu'il ne fait quasiment plus d'erreur en codant sur le nommage d'une variable ou autre chose de ce genre à chercher partout pendant des jours d'ou ça vient, par contre, algorithmiquement, mathématiquement et techniquement, le développeur fait des choses largement plus ardus qu'il y a 20 ans.

Certains s'imaginent que coder en assembleur et toute la clique était plus dur que maintenant : faux, c'était un raisonnement à prendre et ensuite ça déroulait tout seul et les problématiques restaient toujours au final simple.

Aujourd'hui le développeur code en PhP, par exemple, qui est hautement plus verbeux, compréhensible, ... mais par contre te code des trucs qui demanderaient aux développeurs de l'époque dont je fait parti de s'arracher intellectuellement les cheveux, voir d'être juste totalement dépassé.

C'est une bonne remarque

Je suis souvent admiratif des "prouesses" faites par les générations précédentes, notamment de la programmation des jeux vidéos sur Amiga où les dev arrivaient à faire des prouesses en exploitant à fond le hardware.

Les anciens matériels étaient nettement moins puissants qu'aujourd'hui, il fallait optimiser les programmes.

Cependant, même si cet impératif d'optimisation n'est plus là, ce qu'on fait aujourd'hui peut être nettement plus ardu, par exemple en CAO / FAO

Ca ressemble un peu au débat la "dévalorisation des diplômes".
Les anciens disent que les jeunes sont moins capables.
Mais, dans le domaine scientifique, par ex en école d'ingénieur, il faut que le diplôme soit "à jour" et on apprend de plus en plus de sujets.
Certes on peut passer un peu rapidement sur certaines bases qui étaient auparavent maitrisées sur le bout des doigts mais parcequ'il faut arriver à la fin à aborder les toutes dernières technologies.
Ainsi l'école où j'ai suivit mes études d'ingénieur, avec prépa intégrée, avait un cursus de 4 ans après le bac lors de sa création dans les années 60, puis c'est passé à 5 ans, maintenant une 6e année est envisagée.