Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter
Discussion :
L'illusion continue
Ce genre d'étude me fais sourire, ça fait des années que l'on entend dire que le développement va être robotisé, automatisé, que n'importe qui va pouvoir produire des logiciels et que les développeurs ne seront plus utiles.
Et bien je fais toujours du développement et les projets ne manquent pas.
Ils devraient renommer le "low-code" en "shit-code", ce serait plus réaliste.
Le low-code est susceptible de remplacer le codage traditionnel d'ici 2024, selon une étude de Mendix
Le low-code est susceptible de remplacer le codage traditionnel d'ici 2024, selon une étude de Mendix, un éditeur de solutions low-code
Qui ravive le débat sur l’avenir du métier de développeur
Le low-code est susceptible de remplacer le codage traditionnel d’ici 2024. C’est ce qui ressort d’une récente é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. C’est un aspect sur lequel ces outils divisent à côté d’autres comme la maintenance des logiciels produits à partir d’outils low-code.
Le low-code et le no-code sont considérés par des intervenants de la filière comme le futur de la programmation de logiciels. Le 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 en fait partie. Grosso modo, son point de vue sur la question est que le low-code et le no-code ne sauraient faire disparaître les développeurs, mais sont des outils qui leur sont destinés afin qu’ils gagnent en productivité. Ce dernier milite donc pour que ce soit même les développeurs qui soutiennent l’adoption des outils low-code dans les entreprises. La question divise néanmoins dans le milieu sur des aspects comme la maintenance des logiciels produits à partir d’outils low-code.
L’intégralité du positionnement du fondateur de la startup Bubble
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 en utilisant 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 : sondage, Bubble, Hosk
Et vous ?
Les chiffres de ce sondage collent-ils avec la réalité dont vous êtes au fait ?
Voir aussi :
Contribuez au club : Corrections, suggestions, critiques, ... : Contactez le service news et Rédigez des actualités
Comme d'habitude c'est une société qui promeut son produit low-code.
Des décideurs qui possède trop peut de connaissances en informatique vont se faire avoir par le discours commercial.
Résultat :
- il ne sert pas du tout car on arrive pas à s'en servir
- on arrête de l'utiliser car on se retrouve coincé sur ce que l'on veut faire car ça devient trop complexe pour ceux qui l'utilisent ou l'outil nous limite
- on s'en sert et on est content car on a que des petits besoins/traitements et ça suffit
Hybride, je ne sais pas, je vois surtout des commerciaux pas trop nulles avec l'informatique qui vont faire une application potable en peu de temps.Envoyé par Patrick Ruiz
Bien sûr cette application potable ne sera en fait qu'un POC, mais lui ne va pas comprendre (sous entendu sont vraiment nulles les devs) pourquoi il te faudra 100 fois plus de temps pour faire la "même" chose.
Dans mon job, nous utilisons la plateforme low code Oracle Apex + ORDS.
Celui-ci permet de faire des app crud basée sur une DB oracle rapidement.
Cela génère des pages web dynamiques bien foutues avec du reporting sans se prendre la tête avec du css, javascript ou tag html.
C'est du low code pour des développeurs data qui connaissent le sql sans avoir besoin de maitriser les frameworks web.
il y a des tutos qui se trouvent ici : "https://developer.oracle.com/solutions/create-app-from-spreadsheet"
Je m'autocite sur une étude à propose de facebook
En tant que développeur, je préfère créer une solution avec du java, html, javascript, angular ou react, des librairies open source,... plutôt que d'être dépendant d'un machin no-code qui va absorber une partie des bénéfices, me limiter, me rendre dépendant d'eux, et avec un risque de devoir tout refaire plus tard s'ils augmentent leurs prix ou s'ils tombent en faillite par ex.
Ca n'a rien de neuf le WYSWYG ça existait déjà dans les années 90... Je pense qu'il reste plus d'applis cobol ou RPG à l'heure actuelle que les machins faits avec du WYSWYG, non ? :-)
Voici mes réflexions de vieux routard sur le sujet
D'abord, c'est ne vraiment pas un concept nouveau (access, dbase, lotus domino pouvaient s'apparenter à du low code) salesforces en a fait un très bon élément de marketing
L'idéal étant une solution low-code avec de bonnes API et de bonnes interfaces qui permettent ensuite de faire des choses plus poussées.
Mais tant que les plateformes de low-code/no-code voudront verrouiller (elles ont pas le choix, sinon, elles meurent), ca ne sera pas en choix pertinent hormis pour des solutions simples de collectes et reporting.
Cela manque aussi d'un vrai standard.
Un décisionnaire te dirait que toi aussi tu absorbes une partie des bénéfices.En tant que développeur, je préfère créer une solution avec du java, html, javascript, angular ou react, des librairies open source,... plutôt que d'être dépendant d'un machin no-code qui va absorber une partie des bénéfices, me limiter, me rendre dépendant d'eux
Deux expériences vécues :
un directeur commercial en avait marre de voir ses représentants toujours derrière leurs écrans , décide de faire lui-même un programme, celui dont avait besoin les représentants, Bref il m'appelle et me demande de lui fournir les données et quelques rudiments…
bref 3 semaine plus tard, il m'appelle et le verdict tombe "stop chacun son métier et les vachez seront bien gardées". Il m'a dit "j'ai compris pourquoi ils passent un temps fou et ce n'est pas productif..."
Autre histoire d'un langage dont je ne citerais pas le nom, faisait de la programmation à partir d'un questionnaire élaboré, ça je leur concède, mais quand je, du moins nous sommes penchés sur le code généré HO CATASTROPHIQUE là on 150 lignes suffisait environ 1000 à 2000 lignes et d'un gout tordu bref, il ne fallait jamais avoir à rentrer dans le code, mais là ne s'arrête pas l'histoire la société n'est plus et les sociétés ayant pris ce virage ont perdu beaucoup d'argent de temps et de modifications hyper dangereuse, je suis contant que la société ou je travaillais n'ai pas pris ce tournant qui l'envoyait droit dans le mur.
C'est ce genre de "décision" qui fait que certaines boîtes subissent l'informatique comme un centre de coûts et sont à la traîne, là ou d'autre s'en servent comme accélérateur pour dépasser la concurrenceV
Un décisionnaire te dirait que toi aussi tu absorbes une partie des bénéfices.
Copier c'est copier; voler c'est vendre un CD une vingtaine d'euros!
Code C : Sélectionner tout - Visualiser dans une fenêtre à part
2
3
4
5
6
7
J'ai un jour évalué Mendix avec mes architectes pour un gros projet. C'est sympa pour des petits bazars. Mais dès qu'on monte dans les specs plus costaudes, de la haute disponibilité (99% voire plus), on n'y est malheureusement plus.
Apex est puissant,
mais ORDS est une vrai merde pour faire du restfull bien documenté avec un contrat open API correct.
- Tu te retrouves a documenter les API à la main ( Bonjour le suivi quand un package change) ...
- Dire au dev qui ne maitrise pas pl/sql, ben allez lire la proc pl/sql qui se cache derrière...
- Sql dev permet maintenant l'import d'un contrat api qui génère l'interface REST coté ORDS (mais c'est utile que pour initialiser l'API)
Et le mauvais côté en plus avec ORDS, c'est que les décideurs se sont dit chouette les dev dédiés pl/sql vont pouvoir faire les API ( sans formation) et ça va couter moins cher.
Au final quand t'a compté :
- les normes ( POST , PUT , GET, PATH, DELETE + conceptions orienté ressource)
- la gestion des codes retours http
- la formation des experts SQL + la résistance au changement
ben ça te coute beaucoup plus cher qu'un JDBC + couche java/.net d'api
pour faire propre Oracle serai obligé de modifier les Types customisé ( voir resultSets) pour ajouter une syntaxe d'annotation tout en s'assurant que ça casse pas l'existant, et ça j'y crois pas trop.
donc de notre côté après des années d'ORDS imposé, on reviens en arrière (au moins pour les services ayants une complexité importante)
Faut vraiment rien savoir du domaine pour faire des prévisions pareil.. Au dela de la bêtise profonde de l'affirmation, on risque certainement pas de passer des langages utilisés aujourd'hui a quoi que ce soit d'autre en 2024. Et encore moins pour des solutions no code.. Pour moi, le no-code a de l’intérêt dans des applications comme les VFX, la definition de scenario ou de comportement pour les jeux. Enfin ouai, encore un article sponsorisé j'imagine parce que franchement le niveau d’intérêt pour un lecteur est bien en dessous de zéro et aller faire des projections pareil pour dans 2 ans faut vraiment pas avoir de culture informatique, qui a oublié ici que Cobol est toujours utilisé? Je comprends qu'il faille faire de l'argent, mais je me sens quand meme un peu pris pour un c** quand meme la.
Tous les jours, je vois sur linkedin des vendeurs de poireaux
euh ...
de lowcode ou nocode, scander à quel point c'est l'avenir et les boites peuvent oublier les développeurs.
J'ai même moi, dans le parc des entreprises avec lesquelles je bosse, une montée en charge exponentielle depuis 8 mois sur les demandes de ce type de service.
Les entreprises pensent vraiment que c'est outil ou tu allumes ton micro et tu dis :
- pour noël, je veux que le site se fabrique tout seul, gère toute ma compta, toute l'entreprise, me fasse un SAAS ainsi que un gain de 800% de rentabilité, merci.
Moi qui fait à 90% du sur mesure, bon courage pour arriver à leur faire comprendre que c'est la même chose qu'un outil SQL basique avec une interface web mieux travaillée pour faire genre et que s'ils veulent un véritable outil, ils seront toujours obligés de passer par une vraie équipe de développeurs.
Les mecs ne veulent rien savoir, à cause ces vendeurs de poireaux qui en plus, se font une fortune en faisant croire que cette "mer**" va leur sauver la vie.
Il y a de très bon produits low code (plotly.js), comme de très mauvais (Power Apps). Généralement, la caractéristique d'un bon outil low code est de remplir une fonction spécifique, et d'un mauvais de vouloir faire papa-maman.
Il y a qelques temps on a demandé une "petite application" (petit périmètre, peu de fonctionnalités, un fonctionnement attendu facile à écrire et à comprendre) pour remplacer un de nos outils qui est amené à disparaitre.
Attention il y a plein d'imprécisions dans la suite venant essentiellement du fait que je ne suis un "client éclairé" de la DSI mais ni un dev ni un chef de projet :
Le chef de projet nous "vend" une plateforme web intuitive et facile à développer qui permet sortir vite une version de qualification.
Hier le dev nous présente sa première version, c'est super bien, quelques ajustements à faire mais rien d'inquiétant.
Pendant la demonstration il se rend compte qu'il a oublié de rétablir la valeur d'un paramètre, il ouvre son code, trouve assez vite le paramètre et le modifie.
On finit la réunion.
Mon responsable interpelle le chef de projet pour lui reprocher que le projet n'est pas ce qu'il nous avait vendu : une application facile à développer et donc en low-code.
La réponse du chef de projet m'a beaucoup fait rire : Il nous a jamais vendu du low code : il nous a vendu un package efficace : rédaction de cahier des charges + développement rapide et évolutif pour des projets simples.
Ce que je constate:
Les projets sortent en quelques semaines
Pendant la validation les évolutions (cahier des charges compris) sont intégrées plsu vite qu'on ne sait les tester.
Ce que j'ai vu du code n'est pas facilement interprétable pour le néophite que je suis mais le dev s'y retrouve très facilement (meme après quelques mois)
Bref:
Un projet simple bien géré est aussi efficace que du low code (et probablement plus évolutif)
Intéressant de lire que le sujet fait débat, et de constater une certaine fronde des Dev.
Les développeurs "garants de l'expertise" aux yeux des décideurs ne sont peut être pas assez objectifs quant à a l'utilisation de ces technologies ?
Dans un contexte de pénurie des profils développeurs pour les entreprises et donc une augmentation des salaires, cette fronde ne viendrait-elle pas d'une peur de voir son expertise se limiter et devenir une commodité ?
Ce qui me fait me questionner quand je peux lire, un certain dégout d'une population commerciale, quand eux mêmes font spéculer le marché avec leurs propres expériences.. CQFD
Je suis convaincu que ces technologies vont permettre d'accélérer la création d'applications d'entreprise ou simplement pour répondre à des besoins simples, mais il faut à mon sens en définir un scope claire et adresser une conduite du changement adapté à chacun pour qu'à tous les étages d'une entreprise nous puissions identifier des bénéfices (soft value & hard value).
++
Je ne pense pas que ce soit ainsi qu'il faille l'interpréter.
Les développeurs sont fainéants et je suis bien placé pour le savoir : moins ça leur donne de boulot à faire, plus ils sont content.
Ils ne sont pas contre le "low / no" code parce qu'ils veulent garder la main mise sur un secteur, mais parce qu'ils savent très bien, grâce à leur expertise que les boites se font mettre "de la poudre de perlimpinpin".
Ce que propose un outil no ou low code, un bon développeur peu faire mieux en autant, voir moins de temps, mais surtout, avec derrière du code réellement maintenable, robuste, ...
Des requêtes SQL qui ne sont pas des chaines absolument immondes, de surcouche de surcouche, ...
Tout simplement car ce genre d'outils ne pourra jamais de toute manière être optimisé, le seul moyen que ce le soit, serait que ce soit une IA qui recode à la volé le code généré, d'ici là, de nombreuses années vont encore se passer.
Je comprends totalement qu'une boite se dise "les devs sont tous des con****", je n'ai pas envie de payer 200k alors que j'ai un outils gratuit qui me fait la même chose en quelque clics, mais ça, c'est l'éternelle question du "quand on ne veut pas réfléchir, il faut en assumer les conséquences derrières".
Qui arrivent toujours, très vite, à moyen et long terme.
Il n'y a pas besoin de ce genre d'outil pour ça, un simple fichier Excel en réalité produit le même résultat pour créer un business et tester si l'idée est bonne, par contre je ne te rejoins pas sur le fait que ce soit grâce à cet outil, que ça va permettre d'avoir des outils qui vont faire un bond aux boites.
Ca va surtout faire comme le métier de développeur en 2022 : des légions de développeurs version LIDL, ou les boites se rendent compte au bout de 2 ans, que ceux qu'ils embauchent ne font juste pas l'affaire car trop mauvais, pas le cerveau pour, ... et qu'en bref, à vouloir prendre du low coste, il faut assumer les conséquences.
Ce qui se traduit dans la majorité des cas par des fermetures de boites à la place de la pseudo révolution du marché qu'on nous vends.
Les développeurs sont fainéants et je suis bien placé pour le savoir : moins ça leur donne de boulot à faire, plus ils sont content.
Justement c'est une opportunité je pense pour accélérer et shifter ce qui fait perdre du temps pour peu de valeur.
Je comprends totalement qu'une boite se dise "les devs sont tous des con****", je n'ai pas envie de payer 200k alors que j'ai un outils gratuit qui me fait la même chose en quelque clics,
Je ne suis pas d'accord, avec cette remarque qui n'a pas de sens. 200K sera jamais le salaire d'un dev, et les outils LowNoCode ne sont pas gratuits.
Cependant, je te rejoins sur rien de remplacer un dev, et j'en suis le premier convaincu.
Il 'n y a pas de révolution du marché, c'est une évolution, il faut juste (et c'est difficile) trouver le bon outil pour les bons cas d'usages..
Le salaire d'un dev ... en France. (quoi que si, certains devs ont ce salaire, même en France)
Et je ne vois pas le rapport avec le salaire d'un développeur, je parle de la facturation d'une application, c'est ce que prétends faire un outil low ou no code, remplacer l'emploi d'un développeur pour réaliser une application.
200k c'est clairement peu dans le cadre de la facturation d'une application.
Je gère une boite, donc je comprends totalement la problématique lié au fait de trouver un outil plutôt que de payer un développeur ou devoir facturer une application.
Mais dans la majorité des cas, ça répond au besoins du process business, c'est à dire tester des idées, et dans ce cas, je suis pour, car, comme je l'ai indiqué en réalité un simple Excel fait le même travail, voir parfois en mieux, sauf qu'on est plus proche de l'air soviétique en termes de graphisme donc ça fait moins "so 2022".
Là ou en tant que dev et chef d'entreprise je ne suis pas d'accord, c'est quand ça commence à remplacer une application dont le but est de faire vivre un business, ça, en réalité, c'est tomber dans un piège.
Vous avez un bloqueur de publicités installé.
Le Club Developpez.com n'affiche que des publicités IT, discrètes et non intrusives.
Afin que nous puissions continuer à vous fournir gratuitement du contenu de qualité, merci de nous soutenir en désactivant votre bloqueur de publicités sur Developpez.com.
Répondre avec citation
Partager