Discussion :

[el_slapper]

Assez d'accord avec vous tous. Ca m'a aussi refait penser à ce très vieux mais toujours pertinent article sur la matière du code.

Un programme informatique, c'est fait de décisions. Que le code soit apparent (genre un code javascript) ou caché (embarqué dans des outils low-code) ne change rien à cette remarque fondamentale. Or penser les décisions telle qu'une machine va les interpréter, c'est bien là le cœur du métier de développeur. Bien plus que la maitrise de COBOL, JAVA, Angular, ou Rust, la valeur ajoutée d'un professionnel est sa capacité à gérer des ensembles de suites de décisions absolument énormes. Et à les formaliser pour que la machine puisse comprendre. Et, Hosk a raison d'insister là-dessus, à le maintenir pour l'adapter à de nouvelles situations.

Les gens qui veulent utiliser des outils sans code pour se débarrasser des développeurs n'ont pas compris ça. Cacher le code (car il est toujours là, juste encapsulé), ça ne retire en rien sa complexité. Et encore moins la difficulté de maitriser l'ensemble des décisions gérées par le système.

[walfrat]

Honnêtement, étant dans le classique application de gestion de données, faire des outils low code semble parfaitement faisable côté technique.

Alors où est le problème :

• Les IHM, on veut toujours plus de beau truc qui ressemble à Amazon/Apple pour des applis à formulaires, ou alors on veut un truc qui fasse des workflow mais qu'on puisse gérer comme une feuille Excel.
• La complexité de la gestion de données, parfois nécessaire, mais franchement souvent venu du fait qu'on veut que l'appli gère "tout les cas techniquement possibles" alors qu'on pourrait avoir un process simplifié et laissé quelques libertés pour les quelques cas plus ténu. Ou simplement le fais qu'on a digitaliser un vieux process manuel sans le retravailler pour mieux tirer prati de la digitalisation.
• La communication entre application, toujours source de divers problème (donné obligatoire d'un côté, pas de l'autre, schéma différent,...)
• La partie plannification aussi où on veut faire des maj automatiques selon l'avancement du planning etc n'est pas nécessairement évident.

En revanche, faire de simple formulaire sans un nombre ahurissant de règle sur chaque champ et les stocker puis coller un workflow dessus, ça marche.

car nombre d'informaticiens aiment bien coder pour coder.

Pour le coup je ne suis pas d'accord sur cette affirmation par rapport à ton contexte. Ceux qui aiment coder pour coder sont plutôt ceux qui te balancent toutes les nouvelles technos à la figure sans mesurer si ça colle aux besoin du projet. Ceux dont tu parles dans ton post c'est plutôt l'autre côté du spectre : des personnes qui sont au mieux en mode "boulot pour la bouffe" mais qui au moins font le boulot ou au pire des personnes qui n'en ont rien à foutre.

[TJ1985]

Après savoir sévi une petite quarantaine d'années dans le domaine, je suis toujours surpris du nombre de fois que les vendeurs de perlimpinpin parviennent à se faire entendre.
COBOL a été créé pour que des comptables sans autre formation puissent développer des applications de gestion. Il y a eu le pire, mais aussi parfois le meilleur, avec des applications qui tournent depuis plus de trente ans lorsque le domaine du problème n'a pas (trop) changé.
Les 4GL ont été créés pour permettre à monsieur tout le monde de développer sa petite application (toujours de gestion) le soir, devant la télé. Vous connaissez beaucoup d'entreprises qui s'appuient sur des 4GL aujourd'hui ?
Il y a le cloud über alles, cette magnifique récupération des services que peuvent rendre les ordinateurs au profit de quelques entreprises, la ré-instauration du système central et de ses contraintes.
Et dans la foulée la promotion des langages de scripting, sensés résoudre tout, partout, sans qu'on n'ait besoin d'y penser. Du coup, utilisés par des lambdas, ils nous envoient sur des sites tels ceux de l'administration (francaise) ou de certains grands groupes qui tentent de concurrencer Amazon.
Et on se rend compte au final que tant qu'un problème est mal formulé, tant que les gens qui y travaillent sont peu compétents, on pourra faire ce qu'on veut, la solution proposée sera la plupart du temps mauvaise, inefficace et coûteuse. Et ce quel que soit le système de développement utilisé.
Mais ça semble si évident que ce débat même interroge.

[electroremy]

Tout dépend ce qu'on appelle un dev 'professionnel'

Actuellement, beaucoup de gens codent en open source, codent pour eux-même à titre privé ou codent pour leur travail sans être programmeur "de métier" et parfois même de formation.

L'exemple typique c'est :
- le VBA intégré à Excel dans le monde de l'entreprise
- Visual Basic ou Arduino pour la programmation "loisir"

Dans ces domaines il peux y avoir des autodidactes avec un très bon niveau.

J'ai appris la programmation en autodidacte avec GFA Basic sur Amiga puis Visual Basic 3 sur PC

Puis j'ai eu des cours de programmation en école d'ingénieur généraliste (bases de données, POO et UML, c++, informatique industrielle, microprocesseur), mais l'informatique n'était pas la matière principale.

Bref, encore une affirmation qui ne veut pas dire grand chose.

[sam01]

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.

[electroremy]

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.

Je connais bien Wordpress, je m'en sert pour gérer un blog dans le cadre de mon activité professionnelle

Mais ça n'a rien à voir avec le sujet :

« 80 % des technologies pourraient être créées en dehors de l'informatique d'ici 2024, grâce aux outils low-code »

Créer un blog avec WordPress ne consiste pas à créer une nouvelle technologie ou un nouveau logiciel

Un site web n'est pas vraiment un logiciel, en tout cas pas ceux créés avec WordPress

Avec WordPress, on ne peux pas créer une fonctionnalité inédite, par exemple un logiciel en ligne de dessin de circuit imprimés, là il faut faire du code "à l'ancienne" avec JavaScript côté client et PHP côté server.

Au lieu de dire
"Wordpress, c'est bien un outil qui a permis à des non développeur de faire de sites Web"
on pourrait dire
"Wordpress, c'est bien un outil qui a permis à des non développeur de publier sur Internet"
ce qui n'est pas tout à fait la même chose

Un peu comme les PC personnels, les imprimantes et les traitement de texte qui ont "permis à des non imprimeurs de faire des livres"

A bientôt

[electroremy]

Mais, au juste, un outil "low-code", c'est quoi ?

Si c'est assimilable à un langage de programmation, alors la question est absurde, car l'utilisateur d'un outil "low-code" sera donc programmeur.

Regardons en arrière...

Les débuts de l'informatique, c'est du câblage de relais, de tubes à vides puis de transistors.
Est arrivée la programmation en assembleur avec des cartes perforées ou des interrupteurs.

Puis le langage FORTRAN et BASIC sont apparus... pour ceux qui perforaient des cartes ou manipulaient des interrupteurs pour entrer du code assembleur, FORTRAN et BASIC ont permis à des "non informaticiens" de créer des logiciels.

Sauf qu'une personne qui écrit un programme en FORTRAN et en BASIC est bien un programmeur, donc la question n'a pas vraiment de sens.

[Asaty]

Je ne comprends pas le but de l'article ...

depuis le WYSIWYG ... et son <HtmlHtmlHtml> généré lorsqu'un site est compilé </HtmL></HtmL></BR>.
les outils pour une utilisation simplifiée et surtout la création de logiciels par des novices,
( ou des personnes sans aucune notion de ce qu'est un logiciel ) ont pu créer leurs logiciels, leurs sites web ( Wix , Wordpress , Wiki , PhpBB , Madrid ),

C'est l'émulation de tout les internautes, et les outils disponibles, qui ont peuplés les serveurs.

L'ingnièrie n'est pas obligatoire sur la Toile, pour être créateurs , producteurs de 'technologies',
c'est aussi des outils d'automatisation , ce sont des fabriques , des 'factory' dédiées.

Le succés est déjà constaté ( facile d'utilisation ; souvent gratuits ; porteurs d'affaires ),
Et même un professionnel a le droit de s'en plaindre .

Quant aux projections .. n'en faites pas un reluisant sac de noeuds.

Mais le PC ( Personnal Computer ) , ? c'était pour qui au fait ?

[ On veut me refiler des GPS locator GAming , j'y comprends rien moi... ]

Dit avec des chiffres :
Les glaçons ont bientôt quitter les pôles, un nouvel eldorado apparait , c'est quoi le code du wifi ?
C'est la ruée vers le hat !


EDIT :
le low-code est 'stack' et 'hardware' compliant.
Sur des contraintes matérielles et logicielles "inconnues" ( l'hétérogénéité sur des systèmes qui ne sont pas du même domaine ... c'est compliqué aussi ), le /middle-ware/ sera 'low code'.

C'est aussi, beaucoup d'enthousiasme, qu'un travail 'novice'.

Les besoins en formation sont criants, sans commune mesures... et les évolutions technologiques encore quotidiennes.
Est ce que le 'seuil en masse critique' est dépassé ? ou encore imperceptible ?

[Mingolito]

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

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

Ça permettrais en théorie à un client ou à un Devops directement de concevoir une appli visuellement au lieu de donner le job à une équipe de développement.

Ça fait le buzz car un tas de sociétés proposent des solutions la dessus.

La question c'est est ce que c'est de la pub marketing à la noix ? ou alors est ce que dans les faits ça peu marcher ?


Moi j'en pense que même si ça marche un peu pour certains pour certains trucs, ça n'empêche qu'on aura encore plus de besoin de bons de codeurs, donc ça ne met pas du tout en danger le job de développeur.

[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)

[chef_phi]

Les incohérences dans les applications proviennent davantage de l'incapacité des développeurs à réaliser une analyse correcte du problème à résoudre à l'aide du code, que du code lui même.
Rien ne change en ce domaine. Combien de fois n'ai-je pu que déplorer d'avoir été appelé à étudier des applications développées par des amateurs "éclairés", qui s'étaient évaporés sous d'autres cieux après s'être fait mousser auprès des "responsables" au détriments des professionnels, Donner une caisse à outils de qualité à un beau parleur qui n'a d'autres ambitions que de faire parler de lui ou de vendre n'importe quoi le plus cher possible ne résoudra jamais la question de base : à quoi va bien servir cette fichue application? Autant de responsables de la commande, autant de sons de cloches.

Je suis en retraite depuis bientôt deux ans, et je programme enfin pour me faire plaisir. Il était temps.

[el_slapper]

Après savoir sévi une petite quarantaine d'années dans le domaine, je suis toujours surpris du nombre de fois que les vendeurs de perlimpinpin parviennent à se faire entendre.
COBOL a été créé pour que des comptables sans autre formation puissent développer des applications de gestion. Il y a eu le pire, mais aussi parfois le meilleur, avec des applications qui tournent depuis plus de trente ans lorsque le domaine du problème n'a pas (trop) changé.(.../...=)

ça me parle, COBOL a été mon gagne pain pendant 8 ans. COBOL, ça marche très bien. Aussi longtemps que c'est confié à des développeurs.

[chef_phi]

Comme certains dans ce forum, j'ai débuté comme informaticien dans les années 1980, et j'ai cessé cette activité en 2019. C'est dire si j'en ai vu des évolutions.
Mais je ne dirai jamais que globalement c'était mieux avant, pour tout un tas de raisons qui nécessiteraient l'écriture d'un ouvrage entier. En gros, je déplore surtout la baisse du niveau de "conscience" des développeurs au fil des décennies.
Je pense surtout à l'un d'entre eux, le plus caricatural, auquel j'avais demandé un cahier d'exploitation avant d'intégrer son "œuvre" sur notre plateforme d'hébergement .
réponse : "c'est quoi ce machin ? Moi quand je programme je pose une brique. Si elle tient, j'en pose une autre, et ainsi de suite..."
Quand nous avons fait tourner son application sur une plate-forme de test elle avait des performances lamentables, et nous nous sommes trouvés en accusation côté exploitation car il avait fait une démonstration avec son portable à ses "clients", et à cette occasion les performances avaient été à la hauteur.
Sauf que les clients en question se sont contentés d'une démonstration car ils ignoraient ce qu'est une réception de travaux en bonne et due forme. Lorsque des fonctionnalité se sont avérées manquantes, où défectueuses, j'ai réclamé le cahier des charges de l'application signée par les deux partis. Silence gêné de part et d'autre, il n'y avait même pas de document d'analyse du besoin. Ne parlons pas des trois cycles : conceptuel, organisationnel, opérationnel. J'ai n'ai pas réussi à leur faire comprendre qu'une application qui donne vie à trois Snoopy et à deux Mickey n'est pas la même chose en terme d'étude qu'une application de gestion destinée à quelques centaines d'utilisateurs disséminés sur plusieurs sites.
Par la suite, j'ai vu se développer la mode des Frameworks. Combien de programmeurs sont capables d'optimiser le code qu'ils produisent avec une Framework? Alors j'imagine ce que cela va donner avec le Lowcode.
On me répondra comme d'habitude tes serveurs sont mal paramétrés, le réseau n'est pas assez dimensionné, la virtualisation ralenti l'application, etc...
J'ai tout entendu, et je dis aujourd'hui : "au suivant".
Bonne journée,

[GLDavid]

Comme certains dans ce forum, j'ai débuté comme informaticien dans les années 1980, et j'ai cessé cette activité en 2019. C'est dire si j'en ai vu des évolutions.
Mais je ne dirai jamais que globalement c'était mieux avant, pour tout un tas de raisons qui nécessiteraient l'écriture d'un ouvrage entier. En gros, je déplore surtout la baisse du niveau de "conscience" des développeurs au fil des décennies.
Je pense surtout à l'un d'entre eux, le plus caricatural, auquel j'avais demandé un cahier d'exploitation avant d'intégrer son "œuvre" sur notre plateforme d'hébergement .
réponse : "c'est quoi ce machin ? Moi quand je programme je pose une brique. Si elle tient, j'en pose une autre, et ainsi de suite..."
Quand nous avons fait tourner son application sur une plate-forme de test elle avait des performances lamentables, et nous nous sommes trouvés en accusation côté exploitation car il avait fait une démonstration avec son portable à ses "clients", et à cette occasion les performances avaient été à la hauteur.
Sauf que les clients en question se sont contentés d'une démonstration car ils ignoraient ce qu'est une réception de travaux en bonne et due forme. Lorsque des fonctionnalité se sont avérées manquantes, où défectueuses, j'ai réclamé le cahier des charges de l'application signée par les deux partis. Silence gêné de part et d'autre, il n'y avait même pas de document d'analyse du besoin. Ne parlons pas des trois cycles : conceptuel, organisationnel, opérationnel. J'ai n'ai pas réussi à leur faire comprendre qu'une application qui donne vie à trois Snoopy et à deux Mickey n'est pas la même chose en terme d'étude qu'une application de gestion destinée à quelques centaines d'utilisateurs disséminés sur plusieurs sites.
Par la suite, j'ai vu se développer la mode des Frameworks. Combien de programmeurs sont capables d'optimiser le code qu'ils produisent avec une Framework? Alors j'imagine ce que cela va donner avec le Lowcode.
On me répondra comme d'habitude tes serveurs sont mal paramétrés, le réseau n'est pas assez dimensionné, la virtualisation ralenti l'application, etc...
J'ai tout entendu, et je dis aujourd'hui : "au suivant".
Bonne journée,

Je crois que tu as tout dit! Je suis dans la même position que toi et pour ma part, même en tant que fournisseur de services et de développement logiciel, quand je vois que des entreprises se prétendant 'pilotée par la qualité' me rendent un cahier des charges (quand il existe) tenant sur un post-it, alors, elle peuvent s'attendre à recevoir un produit à la hauteur de ce cahier des charges.
Le no-code a ses avantages et ses inconvénients. Quelqu'un disait fort justement que le no-code était en réalité un alignement de blocs logiques. Cette personne a raison. Un bon exemple de no-code dans ma profession est pipeline pilot (https://www.3ds.com/products-service...ipeline-pilot/) ou encore Knime (https://www.knime.com/). Ma pensée quand à ces logiciels sont: OK, ça aide bien pour le business associé (recherche de molécules, édition, fouille de données). Mais derrière, c'est toujours un informaticien qui créé les protocoles. Hors mis Knime qui est open source et gratuit si on se décide à tout faire soi-même, la formule abonnement est très rentable pour Dassault Sytems. Mais ce qui m'effraie c'est que nombre de composants sont faits en réalité avec du code ! C'est pas si no-code que l'on prétend.
Enfin, j'ajoute que si on se donne la peine, l'équivalent pure code existe et on peut recréer ce que font ces logiciels. Leurs avantages est de permettre un développement rapide pourvu que la demande ne soit pas fantaisiste.

@++

[fmartini]

Alors je vais faire court, mais mon opinion à ce sujet est, je pense assez simple.

En effet, selon moi, le no-code/low-code est juste une dénomination un peu plus classe pour dire :

on permet à des incompétents de réaliser des logiciels pour beaucoup moins chère, voir gratuitement.

A entendre par là qu'on donnera la possibilité à l'expert comptable de l'entreprise X de réaliser lui même son logiciel métier et ce, en ne comprenant rien à la programmation logicielle et les patrons de conceptions qui composent cette discipline. Alors certes, ils auront des logiciels fonctionnelles. Mais concernant l'optimisation des ressources pour ne citer que ça, on en sera vraiment très loin au profit d'une grosse économie de fric et sans même fournir de cahier des charges.

Le seul avantage du low-code/no-code est selon moi, comme pour Unity3D et son visual scripting ; de permettre à des non développeur de fournir à des équipes compétentes, un cahier des charges sous forme de prototype.

ps : Ni voyez rien de péjoratif dans mon utilisation du mot incompétent, je parle d'incompétence au sens propre.

[smarties]

Le seul avantage du low-code/no-code est selon moi, comme pour Unity3D et son visual scripting ; de permettre à des non développeur de fournir à des équipes compétentes, un cahier des charges sous forme de prototype.

D'accord sur ce point mais n'oublions pas de toutes petites applications basiques.

Dès qu'il y a de la complexité, je considère qu'il faut faire appel à développement.
Je miserais donc plus sur des framework et des librairies haut niveau.

[fmartini]

D'accord sur ce point mais n'oublions pas de toutes petites applications basiques.

Dès qu'il y a de la complexité, je considère qu'il faut faire appel à développement.
Je miserais donc plus sur des framework et des librairies haut niveau.

Je suis d'accord, mais ne doit-on pas partir du principe qu'une application, même basique est vouée à un moment donnée a évoluer ?

Une pensée à toute les applications "usine à gaz" développé en LabView et vendu en l'état.

[smarties]

Je suis d'accord, mais ne doit-on pas partir du principe qu'une application, même basique est vouée à un moment donnée a évoluer ?

Mais refaire une application basique sur une autre technologie demande peu de temps (faible volume de code, algo simple)

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

[tpericard]

1) Quel est votre avis sur le sujet ?


Les outils low-code doivent rester dans les mains des informaticiens.
C'est juste une autre façon de travailler, pour accélérer le "time to market".
Après tout, on n'est plus à l'époque de l'Assembleur (enfin sur mainframe, j'avais commencé par l'Assembleur dans les années 1980...).
...

3) Pensez-vous que les outils low-code et no-code vont s'imposer ?


Pour des applications simples, à haute valeur ajoutée, et devant être livrée rapidement, oui, c'est parfaitement possible. Mais il ne faut pas en attendre des miracles non plus : si le client n'est pas capable de fournir un cahier des charges décent (pour rester poli), ça ne va pas rendre les choses beaucoup plus facile. Un client fantasque et indécis le restera...


Je me souviens de ceci :
https://en.wikipedia.org/wiki/The_Last_One_(software)
Bien entendu, ça n'a pas duré.
Sans oublier l'incroyable https://fr.wikipedia.org/wiki/Pacbase dont le code généré, et j'en ai vu à la Société Générale, qui est un vrai cauchemar : du code source vomi, je n'ai pas d'autre mot, au kilomètre...D'où https://www.lemagit.fr/actualites/22...-lobsolescence ...

...
Je crains que les outils low-code ne décollent guère, malgré leur avantage indéniable, car nombre d'informaticiens aiment bien coder pour coder.

Bonjour,

Pour Pacbase je trouve que vous êtes un peu dur. Je trouve que ce n'était pas franchement un outil no-code ou même low-code. C'était quand même un AGL qui permettait quand même de faire des programmes selon les besoins de l'époque (années 80 pour ce que j'ai connu). Une partie pénible de la programmation était pris en charge, les déclarations de fichiers, les ruptures et les synchronisations pour la partie Batch et les conversations avec le moniteur CICS pour le TP.

Il y avait en fait un véritable langage qui venait remplacer le COBOL. De plus, il y avait aussi la possibilité de sortie une documentation utilisateur et technique intéressante.

Bref, pour l'époque c'était relativement avancé. Alors, oui, maintenant ça me fait rire effectivement, mais faut se remplacer dans le contexte, ça permettait de sortir des véritables chaines de traitement assez rapidement.

Oui, le code généré était imbuvable mais ce n'était pas ce code généré qui était modifié mais le source Pacbase lui-même.