Dessine moi une appli…
Depuis maintenant plusieurs années, l’IA est devenue publique et accessible à tous, et elle est partout, y compris dans le développement et dans l’écriture du code. Les usages se multiplient, les workflows évoluent, les chaînes de production se recomposent. Selon les contextes, ces outils peuvent accélérer, clarifier ou simplifier, mais ils peuvent aussi déplacer les repères, fragiliser certaines compréhensions et introduire de nouvelles tensions dans la pratique du développement. Ces usages ne sont pas sans remous : ils modifient la manière de coder, de comprendre ce que l’on produit et de se situer face aux outils. C’est de cette interrogation qu’est né cet article : essayer de comprendre ce qui se joue concrètement, et apprendre à composer avec ces outils sans chercher à défendre une position.
Passer le sommaire et commencer la lecture.
- Observer les pratiques et les tensions émergentes : on y pose ce que racontent les développeurs quand ils parlent d’IA dans leur quotidien, entre curiosité réelle, gains visibles et doutes plus diffus sur ce qui change dans leur rapport au code. Ce qu’en disent certains • Un malaise diffus, pourtant partagé • Des pratiques qui se déplacent, des repères qui vacillent.
- Situer l’IA dans la pratique du développement : ici, on quitte le simple ressenti pour regarder comment l’IA s’invite concrètement dans le travail quotidien, dans les outils, les décisions techniques et la manière même d’écrire, relire et maintenir du code. Écrire du code aujourd’hui : compétences, outils et discernement • Le contexte a changé, pas les fondamentaux.
- Apprendre à comprendre en codant : c’est le moment où la pratique devient terrain d’apprentissage, où l’on s’interroge sur ce que l’on comprend vraiment, sur la manière de formuler une demande, de lire une réponse, et de progresser en codant avec l’IA sans lui déléguer le raisonnement. Savoir de quoi l’on parle pour pouvoir douter • Ce que l’IA produit dépend avant tout de celui qui l’utilise • Avant de coder, apprendre à formuler • Apprendre en codant avec l’IA • L’IA comme prothèse, pas comme substitution.
- Une continuité historique des pratiques et des idées : on prend du recul pour se rappeler que ces questions ne sont pas nouvelles, qu’elles traversent d’autres époques et d’autres outils, et que derrière les technologies qui changent reviennent toujours les mêmes enjeux de compréhension, de transmission et de sens. Une histoire déjà connue des développeurs • Une tête bien faite, plutôt que bien pleine.
Observer les pratiques et les tensions émergentes
Ce qu’en disent certains
Avant toute prise de position, il suffit d’écouter les échanges. Dès que l’on parle d’IA et de code, les mêmes remarques reviennent, formulées au détour d’un message, d’un commentaire ou d’une discussion, autour du temps gagné, de l’aide apportée et de ce que cela change, concrètement, dans notre manière de développer.
« Oui, ça marche. Mais dès qu’il faut revenir sur le code, expliquer ce qui se passe vraiment ou reprendre la logique après coup, là, ça devient plus flou. »
« Je gagne du temps sur certaines choses, clairement. Mais parfois, une fois le résultat là, je me rends compte que je ne saurais pas forcément refaire le chemin tout seul. »
« Je m’en sers comme d’un coup de pouce. Après, je me demande souvent jusqu’où ça m’aide vraiment, et à partir de quand ça commence à décider à ma place. »
« Quand une partie du boulot est orientée par un assistant, la question finit toujours par revenir : au final, qu’est‑ce qui relève encore de moi ? »
Ces paroles ne forment ni un discours structuré ni un courant militant. Elles traduisent plutôt une expérience diffuse, faite à la fois d’intérêt, de prudence et d’un questionnement discret sur des repères qui commencent à se déplacer.
On retrouve ce type de remarques dans de nombreux espaces professionnels : dans certains échanges sur LinkedIn, dans des discussions techniques sur Stack Overflow, ou encore dans des articles de fond publiés par A List Apart, Smashing Magazine ou RTInsights, où la question du rôle du développeur, de la compréhension du code et de la responsabilité technique revient de manière récurrente.
Un malaise diffus, pourtant partagé
Les données disponibles confirment ce ressenti. L’usage des assistants d’IA s’est largement répandu, mais la confiance accordée à ce qu’ils produisent reste mesurée. Dans la pratique, le code généré est rarement intégré tel quel : il est relu, corrigé, testé, parfois entièrement repris avant d’être utilisé. Plusieurs analyses, dont « Developers aren’t quite ready to place their trust in AI » publiée par ITPro, soulignent ce décalage entre adoption massive et confiance limitée.
Le code est souvent décrit comme presque correct : fonctionnel, mais demandant encore un travail d’appropriation. Des comparaisons entre code écrit par des développeurs et code généré par IA mettent en évidence des limites récurrentes en termes de lisibilité, de cohérence et de maintenabilité, comme le montre le rapport « State of AI vs Human Code Generation » publié par CodeRabbit.
Pris isolément, ces constats pourraient sembler anecdotiques. Mis bout à bout, ils dessinent pourtant une tension claire : une efficacité immédiate, bien réelle, qui s’accompagne d’un doute croissant sur la compréhension effective de ce qui est produit.
Des pratiques qui se déplacent, des repères qui vacillent
Au‑delà des situations individuelles, les pratiques collectives évoluent elles aussi. Les usages des moteurs de recherche, des forums techniques et d’espaces historiques comme Stack Overflow se transforment, parfois au profit de réponses immédiates, parfois au détriment de discussions approfondies. Cette évolution est régulièrement analysée, notamment dans des articles qui interrogent la place prise par les réponses générées ou assistées par IA « L’IA a‑t‑elle détruit Stack Overflow ? » ou celui de daily.dev « Did Stack Overflow just admit defeat to AI? ».
Le vocabulaire lui‑même évolue. Des termes comme vibe coding apparaissent pour décrire une manière de coder guidée par la suggestion et l’intuition, plus que par une compréhension explicite de chaque mécanisme. Ce glissement lexical traduit un déplacement plus profond : un rapport au code davantage orienté vers le résultat fonctionnel que vers la construction patiente des logiques.
Certaines prises de parole récentes, y compris du côté des éditeurs d’outils (comme l’a récemment exprimé le dirigeant de Cursor), alertent sur le risque d’une fragilisation progressive des bases techniques lorsque la compréhension est reléguée derrière l’efficacité apparente. Ce trouble traverse les profils et les niveaux d’expérience, des débutants aux développeurs les plus aguerris.
Cet état des lieux n’a pas vocation à trancher ni à alarmer. Il permet de poser le cadre : un contexte où les usages évoluent rapidement, où les repères se déplacent, et où la question de la compréhension du code reste centrale. C’est sur ce terrain que s’inscrit la réflexion qui suit.
Situer l’IA dans la pratique du développement
Écrire du code aujourd’hui : compétences, outils et discernement
L’intelligence artificielle fait désormais partie du quotidien du développement. Elle n’est plus une idée à venir ou un sujet de prospective, mais une présence concrète. Elle est déjà là, intégrée aux outils, aux éditeurs, aux environnements de travail, parfois sans même que l’on s’en rende compte, au détour d’une complétion suggérée, d’un renommage automatique ou d’une correction proposée avant même d’avoir été formulée.
Il ne s’agit pas ici de dresser un état des lieux des technologies existantes, ni à comparer les modèles ou les plateformes. Le propos est volontairement déplacé sur la pratique quotidienne du développeur confronté à des projets réels, à des contraintes concrètes, à des choix techniques qui engagent la lisibilité, la maintenabilité et l’usage final d’une application. L’idée n’est pas de déterminer si l’IA est bonne ou mauvaise, mais de comprendre ce qu’elle fait à nos pratiques de codage, d’apprentissage et de décision.
L’angle retenu est donc celui de l’association entre un développeur et une assistance algorithmique, non comme un face-à-face, mais comme une interaction continue. Une relation faite d’apports concrets, de limites structurelles, de gains de temps indéniables, mais aussi de glissements progressifs dans la répartition des responsabilités. L’IA n’est pas envisagée comme une finalité, ni comme une autorité implicite, mais comme un outil parmi d’autres, dont la portée et l’efficacité restent indissociables de la manière dont elle est comprise, interrogée et utilisée.
C’est dans ce cadre que prend place cette réflexion. Elle part de la pratique, de ce que l’on fait réellement quand on écrit du code, pour remettre au centre les compétences, le discernement et la compréhension. Il ne s’agit pas ici de parler d’organisation ou d’économie, mais des pratiques individuelles ou d’équipes.
Le contexte a changé, pas les fondamentaux
L’écriture du code ne se fait plus dans le même contexte qu’il y a encore quelques années. Les outils et les pratiques n’ont cessé d’évoluer. On ne code plus dans un simple bloc‑notes. Les environnements de développement intègrent depuis longtemps des aides multiples : auto‑complétion, linters, snippets de code, générateurs visuels, assistants de débogage. Les plateformes de mutualisation ont banalisé le partage de fonctions, de classes et de bibliothèques encapsulées. Peu à peu, l’usage de librairies est devenu presque indissociable de nos projets, des plus ciblées aux briques désormais incontournables de l’écosystème. Les frameworks eux‑mêmes guident, contraignent et automatisent une partie des choix techniques.
L’arrivée de l’IA générative s’inscrit dans cette continuité. Elle ne rompt pas avec l’histoire des outils de développement, elle en prolonge la logique. Elle modifie la manière dont le code est produit, relu, appris et transmis, non pas en remplaçant les fondamentaux, mais en déplaçant certaines pratiques, certains réflexes et certaines zones de responsabilité.
La démarche proposée ne cherche ni à juger ni à promouvoir ces outils. Elle propose une lecture lucide, ancrée dans la pratique réelle du développement, telle qu’elle se vit sur des projets concrets, avec leurs contraintes, leurs limites et leurs objectifs. L’enjeu n’est pas de savoir si l’on code « avec » ou « sans » IA, mais de comprendre ce que cette nouvelle étape change réellement dans notre façon de penser et de pratiquer le code.
Apprendre à comprendre en codant
Savoir de quoi l’on parle pour pouvoir douter
Aujourd’hui, l’IA rend cette réalité encore plus visible, de manière très concrète et pédagogique. Elle permet de coder, mais surtout d’instaurer un cycle de travail plus riche, à condition de savoir un minimum de quoi l’on parle. Elle peut intervenir dans l’écoute, pour aider à mettre à plat une idée ou un besoin, dans l’échange, pour argumenter, reformuler, recentrer une réflexion, puis dans la production, la correction et l’amélioration.
Ce va-et-vient permanent permet d’affiner, d’ajuster, de préciser. Il invite ainsi à évaluer ce qui a été produit, à changer d’angle si nécessaire, à améliorer avant de recommencer. Apprendre avec l’IA ne se fait pas en ligne droite : on avance par essais, par retours en arrière, par ajustements successifs, souvent déclenchés par de vraies remises en question. Il faut douter, et pouvoir douter c’est accepter de ne pas tout maitriser, sans abandonner l’idée de fond qui s’est construit par notre expérience. Cette zone de flou, d’incertitude, n’a rien d’un défaut, au contraire, elle fait partie du travail. C’est souvent là que l’on peut ajuster, corriger, pour mieux avancer.
Travailler ainsi demande un équilibre permanent. Il faut savoir reconnaître ce qui nous échappe, ce que l’on ne voit pas encore, tout en s’appuyant sur ce que l’on sait faire, sur l’expérience acquise et sur la compréhension que l’on a déjà du code. Douter ne signifie pas renoncer à décider. C’est plutôt rester en mesure de revenir sur ce que l’on produit, de le questionner honnêtement, de l’ajuster si nécessaire, et d’assumer ensuite les choix que l’on fait. Mais pour que ce dialogue soit pertinent, encore faut-il disposer d’un socle, même modeste, et savoir comment formuler une demande, lire une réponse et interpréter ce qui en ressort. C’est à cette condition que l’IA devient un véritable outil d’apprentissage, capable d’accompagner la construction d’une pratique et d’ouvrir vers d’autres manières de structurer et de penser le code.
Ce que l’IA produit dépend avant tout de celui qui l’utilise
Selon le niveau de l’utilisateur, l’IA peut être un accélérateur, un révélateur ou un écran. Elle s’inscrit dans un dialogue permanent entre le développeur, l’éditeur et l’assistance algorithmique. L’IA n’est pas passive : la qualité de ce qu’elle produit dépend étroitement de la relation qui s’installe entre ces acteurs, de la manière dont les demandes sont formulées, ajustées, corrigées.
Elle peut ainsi aider à apprendre en décortiquant une syntaxe, en explorant une structure, en comparant plusieurs approches. Mais ce dialogue peut aussi se déséquilibrer. Lorsque l’un des trois décroche, l’outil, l’éditeur ou le développeur, le code produit perd en lisibilité et en sens. Décrocher se perçoit alors moins comme une erreur que comme un glissement discret : l’éditeur suggère sans plus interroger l’intention, l’outil enchaîne sans contexte réel, le développeur suit le mouvement. L’illusion de maîtrise apparaît alors : du code fonctionne, mais sans compréhension réelle des mécanismes sous-jacents, jusqu’au moment où le contexte se complexifie et où il devient nécessaire de recentrer le débat sur ce qui s’écrit réellement.
Comme tout outil, l’IA possède aussi des zones moins visibles. Des raccourcis implicites, des choix opaques, des effets de surface qu’il faut savoir anticiper ou éviter. Reconnaître ces faces cachées fait partie intégrante du discernement attendu du développeur, au même titre que la compréhension du code qu’il produit ou valide.
Dans une minorité de situations, l’assistance atteint cependant ses limites. Malgré des tentatives répétées et des ajustements successifs, aucun résultat réellement fonctionnel n’émerge. Ce blocage n’est pas tant lié à l’outil lui-même qu’à l’absence de repères suffisants pour formuler une demande exploitable, interpréter une réponse ou corriger une proposition inadaptée. Plusieurs analyses récentes soulignent d’ailleurs que les assistants d’IA peuvent se révéler peu aidants, voire contre-productifs, lorsqu’ils sont utilisés sans socle technique minimal ou sans capacité à structurer un dialogue efficace avec l’outil, comme le montrent notamment « Why Most AI Tools Are Useless for Beginners (And Which Ones Actually Help) », « 99% of Beginners Miss These AI Basics » (Medium) ou encore « Why AI Tools Fail When You Don’t Know the Basics » sur dev.to.
Avant de coder, apprendre à formuler
L’un des points souvent sous-estimés dans l’usage des assistants d’IA concerne la manière même d’entrer en dialogue avec eux. La qualité des réponses obtenues dépend directement de la qualité des demandes formulées. Une requête vague, imprécise ou contradictoire produit mécaniquement une réponse floue, approximative ou mal orientée. À l’inverse, une demande structurée, contextualisée et consciente de ses limites ouvre la voie à des échanges bien plus pertinents.
Cette réalité n’a rien de nouveau. Les moteurs de recherche s’appuient sur le langage naturel depuis plus d’une décennie déjà. Savoir chercher, savoir reformuler, savoir préciser une intention a toujours fait partie des compétences implicites du développeur. L’IA générative ne fait que rendre cette exigence plus visible et plus immédiate. Elle ne comprend pas « mieux » parce qu’elle serait dotée d’une intelligence autonome, mais parce qu’elle est capable de traiter très rapidement des formulations complexes, à condition qu’elles soient correctement exprimées.
Avant d’apprendre à coder, il faut donc apprendre à parler, à décrire un contexte, à poser une contrainte, à expliciter une intention. Cette capacité à formuler n’est pas un artifice, ni une compétence annexe. Elle est au cœur même du raisonnement algorithmique. Mal formuler un problème conduit presque toujours à une solution inadaptée, qu’elle soit produite par un humain ou par une machine.
Il est tentant, face à l’IA, de projeter un fantasme d’intelligence neuronale autonome, capable de comprendre au-delà des mots. Ce fantasme brouille souvent les attentes. Même si l’IA comprend plus vite qu’on ne l’imagine, elle ne comprend pas nécessairement ce qu’on lui dit mal. Elle ne corrige pas une intention floue, elle la prolonge.
Dans cette perspective, la précision des requêtes devient une qualité intrinsèque du développeur. Elle engage une posture : respect de l’outil, clarté de la pensée, responsabilité dans l’échange. L’IA ne sert alors plus de défouloir, ni de substitut, mais de miroir exigeant. Elle renvoie à l’utilisateur la qualité de sa propre formulation, de son raisonnement et de sa capacité à structurer une demande. Ce déplacement est fondamental : il rappelle que l’intelligence du dialogue ne réside pas dans la machine, mais dans la manière dont nous choisissons de lui parler.
Apprendre en codant avec l’IA
La question centrale devient alors celle du discernement. Savoir quand s’appuyer sur l’assistance, quand reprendre la main, quand questionner une proposition plutôt que l’appliquer. Ce discernement repose aussi sur la reconnaissance de ses propres forces : la capacité à structurer une logique, à produire du code cohérent et à faire des choix techniques assumés. Même partielle et évolutive, cette vision des langages, des outils et des technologies constitue un socle indispensable pour rester pragmatique et écrire un code lisible, maintenable et durable. Plus que jamais, il s’agit aussi de savoir se remettre en question, s’ouvrir à de nouvelles approches lorsqu’elles sont constructives, explorer sans crainte de sortir de ses habitudes. Revenir sur un choix, reprendre un raisonnement ou corriger une direction n’est pas un échec, mais une composante normale du travail de développement. Écrire du code aujourd’hui, ce n’est plus seulement aligner des instructions, c’est rester acteur des choix techniques, comprendre ce que l’on met en place, et être capable de faire évoluer, maintenir et transmettre ce que l’on produit.
Dans cette dynamique, l’IA peut devenir un guide sur des parcours que l’on n’aurait pas osé emprunter seul. Elle peut aider à apprendre en forgeant, à tester d’autres logiques, à découvrir de nouvelles manières de raisonner. Elle peut aussi devenir un espace d’apprentissage en soi, en permettant de poser des questions sur ce que l’on ne comprend pas, d’interroger une solution, ou de demander des éclaircissements sur un raisonnement, y compris sur la manière de dialoguer avec l’outil lui-même. Utilisée avec recul, elle permet parfois de faire émerger le meilleur de nous-mêmes, en stimulant notre logique et en affinant notre vision algorithmique, sans jamais s’y substituer.
L’IA peut enfin jouer un rôle de passeur : aider à identifier des discussions pertinentes sur des forums, à repérer des échanges sur des dépôts GitHub, à retrouver des réponses argumentées sur Stack Overflow, ou à orienter vers des ressources reconnues comme celles de MDN, CSS-Tricks, Smashing Magazine ou A List Apart. Elle ne produit pas ces savoirs à la place des humains, mais facilite l’accès aux lieux où ils se construisent, se confrontent et se transmettent. Sur ce point, plusieurs lectures insistent sur une idée simple, apprendre avec l’IA revient souvent à apprendre à l’interroger, comme dans « Should You Use AI to Learn to Code? A Developer’s Guide » (Pluralsight), « Student’s Use of Generative AI as a Support Tool in an Advanced Web Development Course ».
L’IA comme prothèse, pas comme substitution
Une manière plus juste d’aborder cette relation consiste à voir l’IA non comme un remplacement, mais comme une prothèse. Non pas quelque chose qui ferait à notre place, mais quelque chose qui accompagne un geste déjà là. Comme des lunettes ou un appareil auditif, elle peut aider à mieux percevoir, à corriger un manque, à rendre certaines choses plus accessibles. Mais elle ne regarde pas à notre place, n’écoute pas à notre place, ne comprend pas à notre place. L’expérience reste humaine, sensible, parfois hésitante. Il en va de même avec le code. L’IA peut suggérer, éclairer, accélérer certains passages. Mais le geste, l’intention, le choix et le discernement restent du côté de celui qui écrit. C’est à cette condition qu’elle devient réellement utile : non pas en remplaçant, mais en accompagnant.
Dans ce processus, l’IA peut parfois aider à clarifier une réflexion trop dense ou mal posée, à recentrer un raisonnement ou à explorer une piste, sans jamais se substituer à la capacité d’analyse du développeur. Appliquée à l’écriture du code, cette analogie permet de sortir du fantasme de l’« humain augmenté » et de ses dérives. Le code n’est pas relégué à la machine. L’IA n’agit pas seule. Elle assiste, suggère, reformule, accélère parfois. Mais elle ne remplace ni la compréhension, ni le doute, ni la capacité à trancher.
Ce sont toujours les choix qui priment : les orientations que l’on décide, les perspectives que l’on dessine, les compromis que l’on accepte. Qu’il s’agisse d’un développeur seul ou d’une équipe qui se coordonne, le pilotage reste humain. En solo, il s’agit de garder une vision d’ensemble, de savoir quand s’arrêter, quand approfondir. En équipe, la question devient collective : cohérence du code, partage des décisions, lisibilité pour les autres.
Quel que soit l’environnement, le chef d’orchestre, le maître d’œuvre, n’est jamais l’IA. Elle peut accompagner le mouvement, proposer des variations, aider à explorer des pistes, mais la direction, le tempo et l’intention restent du ressort de celles et ceux qui conçoivent, écrivent et maintiennent le code.
Une continuité historique des pratiques et des idées
Une histoire déjà connue des développeurs
De ce point de vue, cette question n’est d’ailleurs pas nouvelle. Les développeurs ont déjà traversé des phases similaires, notamment avec l’arrivée d’outils WYSIWYG, de générateurs de fragments PHP ou JavaScript, puis de frameworks de plus en plus assistés. À chaque étape, les moyens de produire ont évolué, parfois suscitant les mêmes craintes ou les mêmes débats.
Pourtant, au niveau applicatif fini, l’enjeu est resté remarquablement stable. Ce qui comptait, et compte toujours, c’est que l’interface rende le service attendu, que l’ergonomie soit cohérente, que l’usage soit compréhensible et utile pour l’utilisateur final. Que le code ait été écrit intégralement à la main, partiellement généré ou assisté, importait moins que la capacité de l’application à remplir sa fonction et à rester maintenable dans le temps.
Être assisté dans la production ne remet pas en cause cette finalité. De la même manière que traverser une rivière à la nage, en barque ou à la voile ne change rien au fait d’avoir relié deux rives, les moyens employés n’altèrent pas l’objectif lorsque celui-ci est clairement défini. L’important n’est pas la pureté du trajet, mais la pertinence du chemin trouvé au regard de la finalité visé.
Une tête bien faite, plutôt que bien pleine
Montaigne formulait déjà, au XVIᵉ siècle, une exigence qui résonne fortement avec nos pratiques contemporaines, et qui ouvre ici volontairement la conclusion de cette réflexion :
« Je voudrais qu’on fût soigneux de choisir [à l’enfant] un conducteur qui eût plutôt la tête bien faite que bien pleine […]. Je ne veux pas qu’il invente et parle seul, je veux qu’il écoute son disciple parler à son tour. […] Qu’il ne lui demande pas seulement compte des mots de sa leçon, mais du sens et de la substance. […] C’est témoignage de crudité et indigestion que de regorger la viande comme on l’a avalée ; l’estomac n’a pas fait son opération, s’il n’a fait changer la façon et la forme à ce qu’on lui avait donné à cuire. »
Cette intuition éclaire avec justesse notre rapport au code et à l’IA. Accumuler des fragments, des réponses ou des solutions toutes faites ne suffit pas. Le plus important n’est pas tant ce que l’on apprend que ce que l’on en fait ensuite. Qu’il s’agisse d’un fragment de code, d’une approche ou d’un processus, il faut pouvoir l’ingérer, le comprendre, puis le réappliquer ailleurs. C’est souvent là que se joue le franchissement d’une véritable étape d’apprentissage.
Dans cette perspective, l’IA peut jouer un rôle analogue à celui du « conducteur » évoqué par Montaigne. Non pas un maître qui impose, ni une voix qui remplit, mais un accompagnateur qui questionne, propose, ouvre des chemins, puis se retire pour laisser le développeur juger, choisir et décider. Elle aide à mettre sur la piste, mais ne marche jamais à la place de celui qui avance.
La finalité reste inchangée : écrire du code qui a du sens, qui rend un service réel, qui s’inscrit dans un usage et dans une durée. Ce qui évolue, ce sont les moyens d’y parvenir. À condition de ne pas confondre accumulation et compréhension, assistance et délégation, l’IA peut alors devenir un outil de maturation, au service d’une tête mieux faite, plutôt que simplement plus pleine.