Des utilisateurs aux créateurs : la nouvelle démocratisation du logiciel
Pendant des décennies, la relation que la plupart des individus entretenaient avec les logiciels était essentiellement asymétrique. Un groupe relativement restreint de professionnels les concevait, les programmait et les distribuait, tandis que les autres apprenaient à les utiliser. Les entreprises et les utilisateurs pouvaient choisir entre différents produits, les configurer dans certaines limites ou combiner plusieurs outils pour répondre à un besoin précis, mais la possibilité de modifier profondément leur fonctionnement — ou de construire une alternative — restait largement réservée à ceux qui possédaient des connaissances techniques. Lorsqu’une application ne faisait pas exactement ce dont une personne avait besoin, les options étaient prévisibles : adapter le processus aux limitations du logiciel, chercher un autre produit, demander une modification au service informatique, engager un développeur ou apprendre à programmer.
L’intelligence artificielle générative commence à modifier cette relation. Non pas parce qu’elle aurait supprimé la nécessité de comprendre la programmation, ni parce que la création de logiciels fiables serait soudain devenue une activité triviale, mais parce qu’elle réduit une distance qui, pendant une grande partie de l’histoire de l’informatique, est restée considérable : la distance entre l’identification d’un problème et la construction d’un outil numérique capable de le résoudre. Une personne peut aujourd’hui décrire un flux de travail en langage naturel, demander la création d’une interface, générer une fonction, connecter des services, transformer des données, construire une automatisation ou produire un premier prototype fonctionnel sans nécessairement maîtriser les langages de programmation qui opèrent sous ces différentes couches.
La distinction est importante. Démocratiser la programmation ne signifie pas transformer l’ensemble de la population en ingénieurs logiciels professionnels. Cela signifie élargir le nombre de personnes capables de considérer le logiciel non seulement comme un produit fini, mais également comme un matériau modifiable. La conséquence potentielle est une transformation de la condition même de l’utilisateur : passer du statut de consommateur d’outils conçus par d’autres à celui de créateur d’outils construits autour de ses propres besoins.
Une démocratisation qui a commencé avant l’intelligence artificielle
L’idée de permettre à des non-spécialistes de construire des programmes n’est pas née avec les grands modèles de langage. Les feuilles de calcul, les macros, les systèmes de gestion de contenu, les outils d’automatisation et, plus récemment, les plateformes low-code et no-code ont progressivement augmenté le niveau d’abstraction à travers lequel les individus peuvent interagir avec les ordinateurs. La recherche sur l’end-user programming — la programmation effectuée par des personnes dont l’activité principale n’est pas le développement logiciel — existe depuis bien avant la génération actuelle d’intelligence artificielle. Une étude présentée à CHI en 2016, par exemple, a analysé plus de 200 000 automatisations publiques créées avec IFTTT et a mis en évidence un écosystème important d’utilisateurs construisant de petits programmes fondés sur des règles du type « si ceci se produit, alors exécuter cela », souvent pour ajouter des fonctionnalités que les applications d’origine ne proposaient pas.
Ce qui change avec l’intelligence artificielle, c’est l’interface et, potentiellement, l’échelle de participation. Une revue systématique publiée en 2026 dans Management Review Quarterly, chez Springer Nature, fondée sur l’analyse de 383 définitions issues de 306 publications, décrit précisément cette évolution des plateformes low-code et no-code. Les auteurs identifient une transition depuis des modèles principalement centrés sur des instructions et des composants prédéfinis vers des systèmes de plus en plus orientés vers l’intention de l’utilisateur, dans lesquels le langage naturel et les agents d’intelligence artificielle peuvent participer à la génération d’interfaces et de logique métier. L’étude désigne cette évolution sous le terme de Programming by Natural Language : les utilisateurs décrivent par texte ou par voix ce qu’ils souhaitent construire, et le système traduit cette intention en une première implémentation qui peut ensuite être affinée de manière itérative.
Dans une perspective historique, l’intelligence artificielle générative peut donc être comprise comme une nouvelle couche au sein d’un processus d’abstraction beaucoup plus ancien. Les programmeurs ont cessé depuis longtemps de saisir directement des instructions binaires ; les langages de haut niveau ont masqué une grande partie de cette complexité ; les bibliothèques et les frameworks ont ensuite encapsulé des opérations de plus en plus sophistiquées ; les interfaces graphiques ont permis de construire certaines applications sans spécifier manuellement chaque instruction ; et le langage naturel commence désormais à agir comme une nouvelle couche intermédiaire entre l’intention humaine et le système qui l’exécute finalement. Le code ne disparaît pas sous cette abstraction, tout comme Internet Protocol ne disparaît pas lorsque quelqu’un utilise un navigateur. Une proportion croissante de sa complexité devient simplement invisible dans l’interaction immédiate de l’utilisateur.
Du logiciel pour des millions au logiciel pour une seule personne
Cette réduction des barrières à la création peut avoir une conséquence économique particulièrement intéressante. Traditionnellement, le développement logiciel était suffisamment coûteux pour qu’il soit généralement plus rationnel, en dehors de certains projets internes, de construire des produits destinés à un grand nombre d’utilisateurs. Une entreprise identifie un problème relativement commun, développe une solution générale et répartit le coût de cette construction entre des centaines, des milliers ou des millions de clients. Cette logique explique une grande partie de l’économie du logiciel commercial : un traitement de texte, un CRM, une plateforme de gestion de projet ou une application de productivité doivent offrir suffisamment de flexibilité pour répondre aux besoins d’utilisateurs dont les processus ne sont jamais exactement identiques.
La diminution des coûts de développement introduit une autre possibilité : des logiciels dont l’audience légitime peut se limiter à une seule personne. Un avocat peut avoir besoin d’un système qui classe certains documents selon des critères propres à sa pratique ; un chercheur peut souhaiter un outil capable de transformer des informations dispersées en une structure adaptée à une méthodologie particulière ; un designer peut automatiser la préparation de fichiers répétitifs ; un administrateur peut créer une interface qui consolide des informations provenant de plusieurs services ; ou un étudiant peut construire un système organisant ses ressources, ses dates et ses notes selon une logique entièrement personnelle. Aucun de ces outils n’a besoin de devenir une entreprise, d’attirer des investissements ou de gagner des milliers d’utilisateurs pour avoir de la valeur. Leur justification économique peut simplement résider dans le fait qu’ils permettent à une seule personne d’économiser plusieurs heures chaque semaine.
Cette évolution permet d’imaginer une catégorie de logiciel personnel beaucoup plus large que celle que nous avons connue jusqu’à présent. Il ne s’agit plus seulement de personnaliser une application existante grâce à quelques paramètres de configuration. Les individus pourraient construire de petites capacités numériques autour de leur propre manière de travailler. Certains de ces systèmes pourraient exister pendant plusieurs années ; d’autres pourraient être créés pour un projet d’un mois puis abandonnés. Dans le modèle traditionnel, consacrer plusieurs jours d’ingénierie à un outil destiné à résoudre un besoin temporaire pouvait être économiquement irrationnel. Si une part importante de cet outil peut être construite de manière conversationnelle en beaucoup moins de temps, le calcul change.
La comparaison avec d’autres processus de démocratisation technologique est utile. Les appareils photo numériques, puis les smartphones équipés de caméras de plus en plus performantes, n’ont pas transformé chaque individu en photographe professionnel, mais ils ont radicalement réduit le coût de production d’une image et entraîné une expansion spectaculaire du nombre de photographies créées. Les systèmes de gestion de contenu ont produit un effet similaire pour la publication sur le Web : ils n’ont pas éliminé le développement professionnel, mais ont permis à des millions d’organisations et d’individus de publier en ligne sans construire un site depuis zéro. Le développement assisté par intelligence artificielle pourrait provoquer un phénomène comparable : pas nécessairement moins de développeurs, mais beaucoup plus de logiciels.
L’émergence possible du microsoftware
À partir de cette logique, il est possible d’introduire le concept de microsoftware : de petites applications, automatisations, scripts, agents ou interfaces conçus pour résoudre un besoin extrêmement spécifique et dont l’existence ne nécessite pas qu’ils deviennent des produits commerciaux autonomes. Le terme est utilisé ici comme un cadre analytique plutôt que comme une catégorie technique formelle. Un élément de microsoftware peut exister uniquement pour recevoir certains fichiers, extraire cinq variables, comparer les résultats à une base de données et générer un rapport ; un autre peut réorganiser les notes après une réunion ; un troisième peut produire une synthèse hebdomadaire ; et un quatrième peut connecter deux systèmes qui n’ont jamais été conçus pour fonctionner ensemble.
L’important n’est pas chaque outil pris isolément, mais l’environnement qui peut apparaître lorsque leur construction devient suffisamment peu coûteuse. Une personne pourrait finir par travailler aux côtés de dizaines de petits systèmes personnels conçus pour éliminer des frictions précises de son quotidien. Au lieu de dépendre exclusivement de grandes applications généralistes, son environnement numérique pourrait combiner des plateformes commerciales, des API, des modèles d’intelligence artificielle et des couches d’automatisation construites autour de besoins individuels. La question quotidienne pourrait alors évoluer de « quelle application existe déjà pour faire cela ? » vers « pourquoi est-ce que je fais encore cela manuellement ? » ou « puis-je créer quelque chose qui fasse exactement ce dont j’ai besoin ? ».
Cette évolution peut être particulièrement importante pour les petites entreprises et les équipes qui ont historiquement été coincées entre deux options imparfaites : utiliser des logiciels génériques qui ne correspondent pas totalement à leurs opérations, ou supporter le coût de systèmes développés sur mesure. L’intelligence artificielle ne supprime pas cette tension — notamment lorsque la sécurité, la disponibilité, la scalabilité ou les obligations réglementaires entrent en jeu — mais elle peut considérablement élargir l’espace intermédiaire dans lequel des solutions plus petites peuvent être construites et maintenues localement.
Le langage naturel comme interface de programmation
L’un des changements les plus visibles de cette nouvelle étape est que la description d’une intention peut commencer à faire partie du processus de programmation lui-même. Pendant des décennies, transformer une idée en logiciel exigeait plusieurs couches de traduction : comprendre le problème, concevoir une solution logique, puis exprimer cette solution au moyen d’une syntaxe suffisamment précise pour qu’un ordinateur puisse l’exécuter. Les modèles génératifs introduisent une nouvelle couche capable de participer à cette dernière traduction. De manière simplifiée, le processus peut être représenté ainsi : intention humaine → langage naturel → représentation technique → code et exécution.
L’importance de cette couche ne doit pas être confondue avec l’idée que le langage naturel posséderait la précision d’un langage de programmation formel. Dire « organise mes documents importants » reste extrêmement ambigu face à une spécification technique. Que signifie « important » ? Que se passe-t-il lorsqu’un fichier est dupliqué ? Où les informations doivent-elles être stockées ? Qui doit pouvoir y accéder ? Que se passe-t-il si la classification échoue ? Que faut-il conserver et que peut-on supprimer en toute sécurité ? L’intelligence artificielle peut réduire l’effort nécessaire pour produire une implémentation, mais quelqu’un doit encore prendre ou superviser ces décisions. C’est pourquoi la programmation en langage naturel ne supprime pas l’ingénierie : elle déplace une partie de l’effort de l’écriture de la syntaxe vers la spécification de l’intention et l’évaluation du résultat.
Les données provenant de grandes organisations technologiques montrent également à quel point l’intelligence artificielle est déjà intégrée à certaines parties du travail d’ingénierie logicielle. Google Research indiquait en 2024 que ses outils internes de complétion de code basés sur l’IA atteignaient un taux d’acceptation de 37 % parmi les ingénieurs et participaient à la production d’environ la moitié des caractères saisis dans le code dans les contextes étudiés. Dans le même temps, Google insistait sur l’importance de mesurer l’efficacité réelle et de distinguer une démonstration techniquement impressionnante d’un outil qui améliore concrètement le flux de travail d’un développeur.
Productivité : une réalité plus complexe qu’il n’y paraît
La réduction des barrières à la création de logiciels ne doit pas être interprétée automatiquement comme une hausse de la productivité. Les données disponibles produisent des résultats différents selon le type d’utilisateur, la nature de la tâche, l’environnement de travail et la manière dont la productivité est mesurée. Une expérience contrôlée menée par des chercheurs de GitHub et Microsoft a montré que des programmeurs utilisant GitHub Copilot accomplissaient une tâche spécifique de création d’un serveur HTTP en JavaScript 55,8 % plus rapidement que les participants n’ayant pas accès à l’outil. Les chercheurs ont également suggéré que les effets pouvaient être particulièrement importants pour des personnes encore en train d’acquérir de l’expérience en programmation.
Il serait toutefois trompeur d’extrapoler cette expérience et de conclure que l’intelligence artificielle rend n’importe quel développeur 55 % plus productif. Un essai contrôlé randomisé publié par METR en 2025 a examiné un contexte presque opposé : 16 développeurs expérimentés travaillant sur 246 tâches réelles au sein de grands dépôts open source qu’ils connaissaient depuis des années. Avant l’étude, les participants pensaient que l’IA réduirait leur temps de travail d’environ 24 %. Même après avoir utilisé les outils, ils estimaient que l’IA les avait rendus environ 20 % plus rapides. Le résultat mesuré était pourtant inverse : dans cet environnement précis, l’accès aux outils d’IA a augmenté d’environ 19 % le temps nécessaire pour terminer les tâches. METR a clairement indiqué que ce résultat ne devait pas être généralisé à l’ensemble du développement logiciel, mais l’expérience reste précieuse précisément parce qu’elle démontre que l’effet de l’IA dépend profondément du contexte dans lequel elle est utilisée.
L’enquête 2025 de Stack Overflow auprès des développeurs révèle une tension similaire entre adoption et confiance. 84 % des répondants ont déclaré utiliser ou prévoir d’utiliser des outils d’IA dans leur processus de développement, contre 76 % l’année précédente, tandis que 51 % des développeurs professionnels indiquaient les utiliser quotidiennement. Dans le même temps, 46 % déclaraient ne pas faire confiance à la précision des résultats générés par IA, contre 33 % qui affirmaient leur faire confiance. Parmi les principales frustrations figuraient le fait de recevoir des solutions « presque correctes » et de devoir consacrer du temps supplémentaire au débogage de code produit par intelligence artificielle.
La conclusion raisonnable n’est donc pas que l’IA « fonctionne » ou « ne fonctionne pas » pour programmer. Il est plus juste d’affirmer que sa valeur varie en fonction de la tâche. Construire à partir de zéro une application relativement bien délimitée, explorer un langage inconnu, générer du code répétitif ou produire un prototype peut bénéficier considérablement des outils génératifs. Comprendre une architecture mature, modifier des systèmes aux nombreux effets secondaires, préserver des garanties de compatibilité ou prendre des décisions dépendant de plusieurs années de connaissance contextuelle relève d’une autre catégorie de problème. Les recherches DORA de Google Cloud publiées en 2025 reflètent précisément cette distinction en décrivant l’adoption réussie de l’IA dans le développement logiciel comme une question de systèmes et de capacités organisationnelles, et non simplement comme l’acquisition d’un nouvel outil.
Lorsque l’écriture du code n’est plus la seule compétence rare
Si la production de certains types de code devient progressivement moins coûteuse, les connaissances techniques ne disparaissent pas ; c’est la distribution de leur valeur qui change. La mémorisation d’une syntaxe précise peut devenir relativement moins différenciante dans certains contextes, tandis que d’autres capacités gagnent en importance : identifier correctement un problème, en définir les limites, le décomposer en composants, concevoir des contraintes, comprendre les données, évaluer les résultats, détecter les exceptions, vérifier les comportements et reconnaître lorsqu’une solution apparemment fonctionnelle est incorrecte.
Dans cet environnement, une personne sans formation traditionnelle en ingénierie peut être capable de construire des outils remarquablement utiles si elle possède une connaissance approfondie de son domaine et sait décrire clairement ses processus. L’expertise d’un médecin, d’un avocat, d’un chercheur, d’un comptable, d’un designer ou d’un spécialiste des opérations peut être combinée à des systèmes capables de traduire une partie de cette expertise en logiciel. Pourtant, cette même possibilité explique pourquoi les développeurs professionnels restent essentiels. Lorsqu’un outil cesse d’être une expérimentation personnelle et commence à gérer de l’argent, des identités, des informations confidentielles, des décisions importantes, des milliers d’utilisateurs ou des infrastructures critiques, comprendre ce qui se passe sous les couches d’abstraction devient encore plus important.
Il est donc plus précis de parler d’une redistribution des compétences plutôt que de leur disparition. Les développeurs professionnels peuvent se concentrer davantage sur l’architecture, la sécurité, l’infrastructure, l’observabilité, l’intégration, l’assurance qualité, la conception de plateformes et les problèmes nécessitant une compréhension systémique, tandis que d’autres utilisateurs construisent sur les couches fournies par ces professionnels. Paradoxalement, plus il devient facile de générer du logiciel, plus il peut devenir important de distinguer une démonstration qui fonctionne d’un système capable d’être maintenu de manière fiable.
Démocratiser le logiciel signifie aussi démocratiser ses erreurs
Une conséquence est inévitable lorsque l’on augmente le nombre de personnes capables de construire des applications : le nombre de personnes capables de construire des applications peu sûres, fragiles ou incorrectes augmente également. Une interface peut sembler parfaitement fonctionnelle tout en stockant des identifiants de manière inadéquate, en exposant des données personnelles, en faisant confiance à des entrées manipulables, en utilisant des dépendances vulnérables, en étant dépourvue de contrôles d’autorisation appropriés ou en produisant des résultats erronés dans des scénarios que son créateur n’avait jamais anticipés.
Cette préoccupation n’est pas hypothétique. Le Center for Security and Emerging Technology de l’Université de Georgetown a identifié trois grandes catégories de risques associés aux systèmes de génération de code par intelligence artificielle : la génération de code non sécurisé, les vulnérabilités présentes dans les systèmes génératifs eux-mêmes et les effets en aval sur la sécurité de la chaîne d’approvisionnement logicielle. Le centre souligne également que ces risques ne seront pas répartis uniformément. Les organisations disposant de davantage de ressources peuvent mettre en place des examens de sécurité, des procédures de test et des mécanismes de gouvernance qui ne seront pas nécessairement accessibles aux individus ou aux petites entreprises.
Le NIST aborde une problématique liée dans son profil du Secure Software Development Framework appliqué aux systèmes d’intelligence artificielle générative. L’organisme souligne que les systèmes fondés sur l’IA héritent des risques traditionnels du logiciel tout en introduisant de nouvelles préoccupations liées aux modèles, aux données, aux entrées en langage naturel et aux nouvelles surfaces susceptibles d’être manipulées. Sa recommandation fondamentale reste pertinente, que le code ait été écrit manuellement ou généré par intelligence artificielle : le développement sécurisé exige des processus de protection, de révision, de validation et de réponse aux vulnérabilités tout au long du cycle de vie du système.
Cela conduit à une distinction essentielle dans toute discussion sur la démocratisation : créer un logiciel fonctionnel et créer un logiciel fiable ne sont pas la même activité. L’intelligence artificielle peut réduire considérablement la barrière pour la première. La seconde continue de dépendre de la discipline d’ingénierie, des tests, de la sécurité, de la maintenance, de la connaissance du domaine et de la responsabilité.
Du Shadow IT au Shadow Software
Au sein des organisations, cette nouvelle capacité crée également un problème de gouvernance. Depuis des années, les entreprises utilisent l’expression Shadow IT pour décrire les technologies, applications ou services adoptés par des employés ou des départements sans la connaissance ni la supervision de la fonction informatique officielle. Les plateformes low-code et no-code avaient déjà étendu ce phénomène ; la génération d’applications à l’aide du langage naturel pourrait le pousser beaucoup plus loin.
Imaginons un employé qui doit automatiser une tâche récurrente et qui, au lieu d’attendre l’approbation d’un nouveau système d’entreprise, crée en quelques heures une petite application reliant une feuille de calcul, une API externe, des documents internes et un modèle d’intelligence artificielle. Du point de vue de l’employé, une inefficacité a été éliminée. Du point de vue de l’organisation, d’autres questions apparaissent immédiatement : quelles informations sont traitées ? Où sont-elles stockées ? Quelles autorisations possède l’application ? Qui la maintient si l’employé quitte l’entreprise ou change de poste ? Que se passe-t-il si une API modifie son comportement ? Existe-t-il une sauvegarde ? Le système respecte-t-il les politiques internes et les obligations réglementaires externes ?
La revue de Springer sur la démocratisation du développement logiciel identifie explicitement le Shadow IT et la dette technique parmi les risques qui doivent être pris en compte à mesure que les plateformes low-code et no-code évoluent vers l’hyperautomatisation et le développement guidé par l’intention. Le résultat probable est l’apparition d’une nouvelle forme de Shadow Software : des centaines, voire des milliers de petits outils, automatisations et agents construits au sein d’une organisation parce que leur coût individuel est suffisamment faible pour que les employés puissent résoudre localement certains problèmes, mais dont l’effet cumulé crée une infrastructure que personne ne comprend ni ne gouverne entièrement.
La réponse organisationnelle peut difficilement se limiter à l’interdiction de ces outils. S’ils répondent réellement à des besoins que les systèmes technologiques centralisés ne peuvent satisfaire assez rapidement, l’incitation à les utiliser subsistera. Le défi consistera donc à construire des modèles de gouvernance capables de préserver la rapidité du développement distribué sans renoncer au contrôle sur les données, les autorisations, l’identité, la sécurité, la traçabilité et la maintenance.
La nouvelle fracture numérique
Parler de démocratisation peut donner l’impression que les inégalités technologiques vont disparaître. Il est plus probable qu’elles changent simplement de forme. Lorsque l’utilisation d’un ordinateur exigeait la maîtrise d’interfaces en ligne de commande, ceux qui connaissaient ces environnements disposaient d’un avantage important. Les interfaces graphiques ont réduit cette barrière mais en ont créé d’autres. Internet a considérablement réduit le coût de publication de l’information, mais n’a pas automatiquement transformé tous les utilisateurs en producteurs capables de construire une influence ou d’atteindre une audience.
Un phénomène similaire peut se produire avec le développement logiciel assisté par intelligence artificielle. La nouvelle séparation pourrait ne plus exister uniquement entre ceux qui savent programmer et ceux qui ne savent pas, mais entre ceux qui savent transformer l’intelligence artificielle en capacité productive et ceux qui se contentent d’en consommer les résultats. Une personne capable de comprendre son propre travail comme un ensemble de processus, d’identifier les tâches répétitives, de concevoir des automatisations, de structurer l’information, d’évaluer correctement une solution et de combiner différents services disposera d’un avantage significatif, même si elle ne mémorise jamais la syntaxe complète d’un langage de programmation.
La culture technologique pourrait donc devoir élargir sa signification. Il ne suffira peut-être plus de savoir utiliser un traitement de texte, une feuille de calcul ou une plateforme particulière. Il deviendra de plus en plus important de comprendre quels processus peuvent être automatisés, quelles informations peuvent ou non être confiées à un modèle, quand un résultat doit être vérifié, quelles autorisations sont accordées et quelles conséquences découlent de la connexion entre différents systèmes. La capacité de construire sera plus largement distribuée, mais la responsabilité de ce qui est construit le sera également.
Davantage de logiciels, pas nécessairement moins de développeurs
Une grande partie du débat public sur l’intelligence artificielle et la programmation prend la forme d’une question sur le travail : si une machine peut écrire du code, combien de programmeurs seront encore nécessaires ? La question est légitime, mais elle suppose peut-être implicitement que la demande de logiciels de la société restera constante. L’histoire d’autres technologies suggère autre chose : lorsque le coût de production de quelque chose diminue fortement, nous avons généralement tendance à en produire beaucoup plus.
Si le coût nécessaire pour transformer un petit besoin en outil numérique fonctionnel baisse suffisamment, des projets qui n’auraient auparavant jamais obtenu de budget deviennent viables. Une petite entreprise qui n’aurait jamais recruté une équipe de développement pour construire dix systèmes internes peut finir par exploiter des dizaines d’automatisations. Une personne qui n’aurait jamais commandé une application sur mesure peut en créer plusieurs. Les équipes professionnelles peuvent expérimenter avec beaucoup plus d’idées avant de décider lesquelles méritent de devenir des produits robustes. Le coût par unité de logiciel diminue, tandis que s’élargit l’univers des problèmes qu’il devient économiquement rationnel de résoudre par logiciel.
Le rôle du développeur professionnel changera presque certainement sous l’effet de cette évolution. Certaines tâches pourront être partiellement automatisées et certaines formes de travail perdront de leur valeur relative tandis que d’autres en gagneront. Mais réduire toute cette transformation à une compétition entre « IA » et « programmeurs » laisse de côté une conséquence beaucoup plus profonde : la frontière qui définit qui peut produire du logiciel est en train de se déplacer.
Des utilisateurs aux créateurs
La révolution la plus importante de l’intelligence artificielle appliquée à la programmation n’est peut-être pas qu’un modèle puisse générer une fonction Python, construire une page Web ou corriger une erreur de programmation. Ces capacités sont techniquement importantes, mais elles font partie d’un phénomène plus large : la réduction du coût nécessaire pour transformer une intention en capacité numérique.
Pendant des décennies, nous avons appris à vivre à l’intérieur de systèmes conçus par d’autres personnes. Nous avons modifié nos processus pour nous adapter à leurs menus, leurs colonnes, leurs formulaires, leurs flux de travail et leurs limitations. La prochaine étape pourrait partiellement inverser cette relation. Au lieu de chercher constamment une application suffisamment proche de ce dont nous avons besoin, nous disposerons de plus en plus de possibilités pour construire des couches logicielles autour du problème lui-même.
Cela ne supprime ni le développement logiciel professionnel, ni l’ingénierie, ni la nécessité de connaissances techniques. Au contraire, ces compétences peuvent devenir encore plus importantes lorsque les conséquences d’une erreur sont plus graves. Cela ne signifie pas non plus que n’importe qui puisse construire de manière sûre n’importe quel système simplement en le décrivant. Les données disponibles sur la productivité, la fiabilité, la confiance et la sécurité imposent une lecture beaucoup plus prudente.
Malgré ces limites, le changement demeure profond. Les plateformes low-code ont réduit la quantité de code nécessaire pour construire du logiciel ; les plateformes no-code ont permis de développer certains systèmes sans interagir directement avec le code ; et les modèles génératifs commencent désormais à réduire la distance entre l’intention et l’implémentation elle-même. Dans certains contextes, la programmation devient ainsi moins exclusivement une conversation entre un programmeur et une machine et davantage une conversation entre une personne, un système d’intelligence artificielle et l’infrastructure capable d’exécuter ce qu’ils définissent ensemble.
Le résultat pourrait être une époque dans laquelle créer de petits outils numériques cesse d’être une activité extraordinaire. Une époque dans laquelle une application peut avoir un seul utilisateur, exister pendant une semaine et rester économiquement rationnelle. Une époque dans laquelle l’automatisation d’un travail répétitif cesse d’être uniquement une décision réservée à un département informatique et devient également une capacité individuelle.
Pendant des décennies, l’utilisateur a dû s’adapter au logiciel. La nouvelle démocratisation du développement ouvre la possibilité inverse : que de plus en plus de logiciels puissent s’adapter à l’utilisateur.
Références
Abendroth et al. The democratization of software engineering: evolution, definition, and the future of low-code and no-code platforms. Management Review Quarterly, Springer Nature, 2026. Voir la publication.
Stack Overflow. 2025 Developer Survey — AI. Données sur l’adoption de l’IA, la confiance, la productivité perçue et les préoccupations des développeurs. Voir l’enquête.
Peng, S., Kalliamvakou, E., Cihon, P., & Demirer, M. The Impact of AI on Developer Productivity: Evidence from GitHub Copilot. Voir l’étude.
Becker, J., Rush, J., Barnes, B., & Rein, D. Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity. METR, 2025. Voir l’étude.
Chandra, S., & Tabachnyk, M. AI in Software Engineering at Google: Progress and the Path Ahead. Google Research, 2024. Voir la publication.
Google Cloud / DORA. 2025 State of AI-Assisted Software Development. Voir le rapport.
National Institute of Standards and Technology. Secure Software Development Practices for Generative AI and Dual-Use Foundation Models — NIST SP 800-218A. 2024. Voir la publication du NIST.
Ji, S., Jun, M., Wu, H., & Gelles, R. Cybersecurity Risks of AI-Generated Code. Center for Security and Emerging Technology, Georgetown University, 2024. Voir le rapport.
Ur, B. et al. Trigger-Action Programming in the Wild: An Analysis of 200,000 IFTTT Recipes. CHI 2016. Voir la publication.
