Avec l'IA, tout le monde peut construire. Concevoir reste un métier

Une IA peut écrire une fonction en quelques secondes. Beaucoup en concluent qu'elle peut construire un logiciel tout entier.

C'est confondre deux métiers. Écrire une ligne de code et concevoir un système qui tient debout dans cinq ans, ce n'est pas la même chose.

Cet article n'est pas contre l'IA. On l'utilise nous-mêmes, tous les jours, en interne. La question n'est pas de s'en passer, elle est de savoir ce qu'elle remplace vraiment, et ce qu'elle ne remplace pas.

Ce que l'IA a vraiment changé dans le développement

L'IA générative a rendu l'écriture de code accessible à quasiment tout le monde. Une personne sans formation technique peut aujourd'hui obtenir un script, une page, une automatisation, en décrivant simplement ce qu'elle veut.

C'est un vrai changement, et il est utile. Des tâches qui prenaient des heures se font en minutes. Des idées qui restaient sur le papier deviennent des prototypes en une soirée.

Chez Lunnar, cet outil fait partie du quotidien. Il sert à construire plus vite une fois qu'on sait quoi construire, exactement comme une machine assiste un artisan sans décider à sa place de ce qu'il fabrique.

Mais produire du code n'a jamais été le point difficile d'un projet logiciel. Le point difficile, c'est de savoir quel code écrire, dans quel ordre, avec quelles limites, et pourquoi.

L'IA répond très bien à « comment faire ». Elle ne répond pas à « faut-il faire, et de cette façon-là ».

Cette confusion n'est pas nouvelle. Elle existait déjà avec le no-code, qui a démocratisé l'assemblage d'outils sans démocratiser la réflexion derrière. L'IA amplifie simplement le phénomène, à une autre échelle.

L'analogie de l'architecte : construire n'est pas concevoir

Un architecte ne pose pas une brique. Il dessine un plan qui décide où va chaque brique, ce que le bâtiment devra porter, et comment il vieillira. Un outil qui génère du code fait à peu près la même chose qu'un accès illimité aux matériaux et aux ouvriers : il exécute vite, il ne pense pas la structure.

Avoir tous les matériaux du monde ne vous dit pas où poser les fondations. Ça ne vous dit pas non plus ce que le bâtiment devra supporter dans cinq ans, quand vous aurez trois fois plus d'utilisateurs, deux fois plus de données, et une réglementation qui aura changé.

Un architecte qui aurait accès à des matériaux illimités irait plus vite. Il ne dessinerait pas moins de plans pour autant. Ce serait même l'inverse : plus la construction est rapide, plus le plan doit être solide avant de commencer, sous peine d'aller vite dans la mauvaise direction.

Le plan avant les fondations

Avant la première ligne de code, il faut décider : comment les données sont structurées, ce qui doit rester séparé, ce qui doit se parler, ce qui doit être protégé en priorité.

Ces décisions ne se voient pas tout de suite. Elles ne se révèlent que plus tard, quand le système grossit et que chaque choix du départ pèse sur tout ce qui a été construit dessus.

Un plan mal pensé ne s'écrit pas en une phrase à une IA. Il se dessine en comprenant un métier, ses irritants réels, et ce qu'il deviendra dans les prochaines années.

Ce qui casse quand personne n'a dessiné les plans

Trois choses cassent, presque toujours dans cet ordre.

La dette technique. Du code qui marche aujourd'hui, mais que personne ne peut faire évoluer sans tout casser autour, parce qu'il n'a jamais été pensé pour bouger.

La sécurité. Des failles qui ne se voient pas à l'usage normal, mais qui s'ouvrent dès que quelqu'un cherche à les exploiter. Elles ne s'ajoutent pas après coup, elles se pensent dès la structure.

Les données incohérentes. Une même information stockée à deux endroits différents, qui finit par se contredire. Un client à deux adresses, une commande à deux statuts. Personne ne sait plus laquelle est la vraie.

Ces trois problèmes n'apparaissent presque jamais le premier jour. Ils apparaissent six mois ou deux ans après, quand il est devenu coûteux de les corriger.

Plus l'outil a été construit vite, plus ces problèmes arrivent tôt. Ce n'est pas un hasard : la vitesse de construction et la solidité du plan ne se compensent pas l'une l'autre.

3 signes qu'un projet a été codé sans être conçu

Ces signaux se retrouvent souvent ensemble, sur des outils construits vite, sans étape de conception préalable.

Personne ne peut expliquer pourquoi une fonctionnalité a été construite ainsi. Le code fonctionne, mais la logique derrière s'est perdue. Chaque modification devient un pari.

Chaque nouvelle demande prend plus de temps que la précédente. Le système n'a pas été pensé pour évoluer, alors chaque ajout se fait en contournant ce qui existe déjà, un peu plus difficilement à chaque fois.

Les mêmes bugs reviennent après avoir été corrigés. Signe que le problème n'a jamais été traité à la racine, seulement maquillé à la surface, parce que personne n'a pris le temps de comprendre la cause.

Aucun de ces trois signes ne se voit sur une démonstration. Ils se révèlent à l'usage, souvent après que l'outil a déjà pris une place importante dans le quotidien de l'entreprise. C'est ce qui les rend coûteux : on les découvre trop tard pour les corriger à bas prix.

Ce que fait un concepteur

Concevoir, c'est décider de la structure avant d'écrire, en pensant à ce que le système devra porter dans plusieurs années, pas seulement à ce qu'il doit faire demain.

Ça veut dire comprendre un métier de l'intérieur avant de proposer quoi que ce soit. Trancher les priorités, écarter le superflu, choisir ce qui doit exister maintenant et ce qui attendra. Poser la structure des données, la sécurité, les automatisations, avant que quiconque écrive une ligne.

Ce travail se fait avant le chiffrage, pas après. Un devis construit sans cette étape n'engage sur rien de solide : il chiffre une intuition, pas un plan vérifié.

C'est exactement ce que décrit notre méthode : une immersion dans votre métier, puis une phase de structuration, avant toute construction. L'IA nous sert ensuite à construire plus vite, mais elle intervient après ce travail, jamais à sa place.

Le résultat de ce travail, c'est un outil qui n'existe que pour vous, dont vous gardez les données sans condition, et qui a été pensé pour durer. On montre ce qu'on sait concevoir en exemples, pas en catalogue de modules.

Un dernier point mérite d'être dit clairement : rien de tout cela n'est contre l'IA. Utilisée après la conception, une fois le plan posé, elle accélère sincèrement la construction. Utilisée à la place de la conception, elle produit vite quelque chose qui aura du mal à vieillir.

Pour comprendre à quel moment un outil du marché atteint ses limites et où la conception sur mesure prend le relais, notre article sur les limites du no-code détaille les seuils concrets. Et si la question qui reste, c'est le prix, notre article sur le coût d'un logiciel sur mesure pose les vrais chiffres.

Si vous avez un projet où cette étape de conception a été sautée, ou si vous démarrez de zéro, le plus simple reste d'en parler directement plutôt que de deviner seul.

Questions fréquentes

L'IA peut-elle remplacer un développeur ?

Elle remplace une partie de l'écriture de code, pas la conception. Décider de la structure d'un système, anticiper ce qu'il devra porter dans cinq ans, penser la sécurité et la cohérence des données restent un travail humain, même avec l'IA comme outil.

Un architecte logiciel, c'est quoi exactement ?

C'est la personne qui dessine la structure d'un système avant qu'on l'écrive : comment les données s'organisent, ce qui doit rester séparé, ce qui doit être protégé, ce qui doit pouvoir évoluer sans tout casser dans deux ans.

Lunnar utilise-t-il l'IA pour construire les logiciels ?

Oui, en interne, pour accélérer la construction une fois le plan posé. Ce n'est pas elle qui décide de l'architecture ni des priorités : ce travail de conception reste fait par des personnes, avant que la première ligne de code s'écrive.

Pourquoi la dette technique arrive-t-elle même avec du code généré par IA ?

Parce que la dette technique vient d'un manque de structure, pas d'un manque de rapidité d'écriture. Du code produit vite, sans plan derrière, s'accumule de la même façon qu'un code écrit à la main dans l'urgence.