Les créateurs de sites IA sont rapides, mais que cache leur code ? Découvrez pourquoi l'architecture et les bases de données restent essentielles pour évoluer.
en
no
frL’IA a changé la manière dont les sites web et les applications sont créés.
Aujourd’hui, vous pouvez ouvrir un générateur de sites web basé sur l’IA, décrire ce que vous voulez en langage naturel, et regarder une application apparaître devant vos yeux.
« Crée-moi un site web pour mon entreprise. »
« Ajoute un formulaire de contact. »
« Ajoute un blog. »
« Permets aux utilisateurs de créer un compte. »
« Ajoute les paiements. »
« Donne-lui une apparence plus haut de gamme. »
Quelques minutes plus tard, vous avez quelque chose qui ressemble à un véritable produit.
Et c’est réellement impressionnant.
Mais il y a une question que beaucoup de chefs d’entreprise ne se posent pas :
Qu’est-ce que l’IA a réellement construit derrière l’écran ?
Parce qu’un site web ne se résume pas à ce que vous voyez dans votre navigateur.
Les boutons, les couleurs, les animations, les images et les textes ne sont que la partie visible.
Derrière tout cela se trouvent des bases de données, des API, l’authentification, la logique métier, du code exécuté côté serveur, des dépendances, de l’infrastructure, des règles de sécurité, du cache, du stockage d’images, des intégrations et des milliers de décisions que la plupart des visiteurs ne verront jamais.
Et c’est là que la différence entre le développement assisté par l’IA et la création de sites web avec l’IA devient importante.
Commençons par clarifier quelque chose.
Je suis ingénieur logiciel, et j’utilise l’IA.
Beaucoup.
L’IA est devenue l’un des outils les plus utiles de mon processus de développement.
Je l’utilise pour prototyper des idées, étudier des problèmes, générer des tests, analyser du code, refactoriser du code existant, comprendre des systèmes que je ne connais pas encore et accélérer le développement.
L’IA ne fait pas de moi un moins bon développeur.
Elle me rend plus rapide.
La différence importante est que je comprends déjà ce que je demande à l’IA de construire.
Je sais ce qu’est un schéma de base de données.
Je sais pourquoi deux tables devraient, ou ne devraient pas, être liées.
Je sais ce qu’est une API.
Je sais ce qui peut se produire lorsque l’authentification est mal implémentée.
Je sais pourquoi un framework peut être plus adapté qu’un autre.
Je sais ce qui peut arriver lorsqu’une dépendance devient obsolète.
Et surtout, je sais reconnaître lorsque le code généré par l’IA est mauvais.
Ce dernier point est beaucoup plus important qu’on ne le pense.
Le mot « IA » donne parfois l’impression que tous ces outils fonctionnent de la même manière.
Ce n’est pas le cas.
Il faut distinguer au moins trois niveaux.
C’est l’intelligence qui se trouve au cœur du système.
Des modèles comme GPT, Claude et d’autres peuvent comprendre des instructions, raisonner sur du code et en générer.
Mais un modèle d’IA, à lui seul, n’est pas votre site web.
On peut plutôt l’imaginer comme un ingénieur extrêmement puissant assis à côté de vous, capable de produire du code lorsque vous le lui demandez.
Les outils utilisés par les développeurs fonctionnent différemment.
Ils peuvent travailler directement dans un projet existant.
Ils peuvent analyser les fichiers, comprendre la structure du projet, modifier certains composants, exécuter des tests, rechercher des erreurs et effectuer des changements tout en conservant le contexte du code existant.
Le développeur reste responsable des décisions d’architecture.
L’IA l’aide à les mettre en œuvre.
Puis il existe des plateformes comme Lovable et d’autres outils similaires.
Elles sont beaucoup plus proches de générateurs d’applications.
Vous décrivez le produit.
La plateforme transforme cette description en application, en générant notamment le frontend, certaines intégrations backend, des structures de données et d’autres éléments nécessaires.
C’est extrêmement pratique.
Mais cela crée également une nouvelle possibilité :
Vous pouvez créer un logiciel sans réellement comprendre le logiciel que vous êtes en train de créer.
Et c’est là que cela devient important pour une entreprise.
C’est probablement l’argument le plus fort.
Et parfois, il est parfaitement valable.
Le site fonctionne.
La page d’accueil se charge.
Le formulaire de contact est envoyé.
Les images apparaissent.
La connexion fonctionne.
Le propriétaire peut même publier le site.
Alors, quel est le problème ?
Le problème est que fonctionner aujourd’hui et constituer une bonne base pour demain sont deux choses différentes.
Imaginez acheter une maison simplement parce que la porte d’entrée s’ouvre.
Cela ne vous dit rien sur la qualité des fondations.
Pour le savoir, il faut regarder ce qui se trouve en dessous.
C’est exactement la même chose avec un logiciel.
Prenons un exemple complètement ordinaire.
Imaginez qu’un coach sportif ouvre une petite salle de fitness.
Au début, il a simplement besoin d’un site web.
Les besoins semblent simples :
Page d’accueil
Présentation
Services
Formulaire de contact
Quelques photos
Peut-être un blog
Il ouvre un générateur de sites basé sur l’IA et crée lui-même son site.
Le résultat est très réussi.
Alors il continue.
« Ajoute un système de réservation. »
L’IA en ajoute un.
« Permets aux clients de créer un compte. »
Maintenant, il faut gérer l’authentification.
« Permets aux clients de voir leurs prochaines séances. »
Il faut maintenant créer des relations entre les clients et leurs réservations.
« Ajoute un tableau de bord pour que je puisse gérer mes rendez-vous. »
Il faut maintenant gérer différents niveaux de permissions.
« Permets aux clients d’acheter un forfait de dix séances. »
Les paiements et les transactions entrent dans le système.
« Déduis automatiquement une séance lorsqu’un client participe à son rendez-vous. »
Nous avons maintenant de la logique métier.
« Envoie un rappel par e-mail 24 heures avant chaque rendez-vous. »
Il faut maintenant gérer des processus en arrière-plan et un service d’e-mail.
« Permets aux clients d’annuler jusqu’à 12 heures avant leur rendez-vous. »
Il faut maintenant appliquer des règles métier quelque part dans le système.
« Ajoute plusieurs coachs et permets aux clients de choisir leur coach. »
De nouvelles relations apparaissent.
« Permets aux coachs de voir leurs propres horaires, mais pas les informations privées des autres coachs. »
L’authentification et les autorisations deviennent maintenant plus sophistiquées.
« Ajoute une liste d’attente lorsque les cours sont complets. »
Encore davantage de logique métier.
Et soudain, le site web initial n’est plus vraiment un simple site web.
C’est devenu une plateforme de réservation.
Et cette transformation peut se produire progressivement, une petite demande à la fois.
C’est là que les choses deviennent intéressantes.
Lorsque je travaille avec un client, l’une des premières choses que je veux comprendre n’est pas la couleur des boutons.
C’est :
Comment l’entreprise fonctionne-t-elle réellement ?
Prenons un système de réservation.
Un client peut dire :
« J’ai besoin que mes clients puissent réserver des rendez-vous. »
Cela paraît simple.
Mais que signifie réellement « réserver » ?
Qui peut réserver ?
Faut-il créer un compte ?
Peut-on annuler ?
Jusqu’à combien de temps avant peut-on annuler ?
Le paiement est-il effectué avant ou après le rendez-vous ?
Que se passe-t-il si le client ne vient pas ?
Deux personnes peuvent-elles réserver le même créneau ?
Que se passe-t-il lorsque le coach n’est pas disponible ?
Un administrateur peut-il modifier une réservation ?
Un client peut-il avoir plusieurs forfaits ?
Comment calcule-t-on le nombre de séances restantes ?
Que se passe-t-il lorsqu’un forfait expire ?
Qui peut voir les informations des clients ?
Que se passe-t-il lorsqu’un paiement échoue ?
Le client doit-il recevoir un e-mail ?
Le coach doit-il également en recevoir un ?
Que se passe-t-il lorsque le cours est complet ?
Ce ne sont pas des questions de design.
Ce sont des questions de logique métier.
Et cette logique métier devient finalement des tables de base de données, des relations, des API, des permissions, des règles de validation, des processus en arrière-plan et du code applicatif.
C’est la partie que la plupart des visiteurs ne voient jamais.
Mais c’est la partie dont votre entreprise dépend réellement.
C’est important.
Un logiciel généré avec l’IA ne devient pas automatiquement mauvais.
Il est tout à fait possible de créer une application très bien structurée avec l’IA.
Le problème apparaît lorsque l’architecture est remplacée par une simple conversation.
Imaginez que vous demandiez continuellement à une IA :
« Ajoute ça. »
« Maintenant, change ceci. »
« En fait, fais-le fonctionner différemment. »
« Ajoute encore un champ. »
« Déplace cette fonctionnalité. »
« Fais de cet utilisateur un administrateur. »
« Maintenant, rends cette page publique. »
« Et connecte aussi les paiements. »
L’IA va essayer de satisfaire chacune de vos demandes.
Et c’est exactement ce que vous lui avez demandé de faire.
Mais pendant ce temps, le logiciel accumule des décisions.
Si personne ne s'occupe de l’architecture sous-jacente, vous pouvez progressivement vous retrouver avec :
du code dupliqué
des structures de données incohérentes
des dépendances inutiles
une hiérarchie de composants difficile à comprendre
des relations de base de données mal conçues
trop de logique exécutée côté client
une validation insuffisante
des règles d’authentification incohérentes
des API difficiles à maintenir
des hypothèses cachées dans le code
trop de services différents
un déploiement de plus en plus complexe
Et le pire ?
Le site peut toujours avoir l’air parfait.
C’est justement ce qui rend ce problème difficile à voir.
Autre chose que beaucoup de chefs d’entreprise ne réalisent pas : il n’existe pas une seule chose appelée « le code d’un site web ».
Il existe différents langages de programmation, frameworks, environnements d’exécution, bibliothèques et architectures.
Deux sites web peuvent avoir pratiquement le même aspect tout en étant complètement différents à l’intérieur.
L’un peut utiliser WordPress et PHP.
Un autre peut utiliser React et Next.js.
Un autre peut utiliser un framework JavaScript différent.
Un autre peut utiliser une plateforme d’application hébergée.
Un autre peut utiliser un backend personnalisé avec une base de données relationnelle.
Ils peuvent tous afficher une page d’accueil.
Mais ils n’auront pas nécessairement les mêmes :
performances
modèles de sécurité
possibilités d’évolution
facilité de maintenance
processus de déploiement
architecture de base de données
capacités SEO
flexibilité
besoins en hébergement
coûts de développement
coûts de développement futurs
Le langage utilisé ne suffit pas à déterminer si une solution est meilleure.
L’architecture et la manière dont la technologie est utilisée sont essentielles.
Une application mal conçue dans un langage moderne peut être pire qu’une application bien conçue dans un langage plus ancien.
La bonne question n’est donc pas :
« Quel est le langage le plus récent ? »
Mais plutôt :
« Quelle technologie et quelle architecture sont adaptées à cette entreprise ? »
C’est probablement la chose à laquelle les entreprises devraient davantage réfléchir.
Ne demandez pas uniquement :
« Est-ce que je peux lancer ce site ? »
Demandez-vous :
« Que se passera-t-il si mon entreprise réussit ? »
Que se passe-t-il si vous avez soudainement dix fois plus de visiteurs ?
Si vous souhaitez ajouter une application ?
Si vous avez besoin de comptes clients ?
Si vous voulez développer une application mobile ?
Si vous voulez créer une marketplace ?
Si vous voulez toucher des clients internationaux ?
Si vous avez besoin de plusieurs langues ?
Si vous voulez connecter un CRM ?
Si vous voulez votre propre tableau de bord ?
Si vous avez besoin d’une API ?
Si une autre entreprise doit intégrer votre système ?
Si vous souhaitez changer de CMS ?
Si votre hébergeur devient trop cher ?
Si vous devez migrer votre base de données ?
Si vous engagez une autre équipe de développement dans cinq ans ?
Ces questions ressemblent à des problèmes futurs.
Elles ne le sont pas.
Ce sont des questions d’architecture que vous devez commencer à considérer aujourd’hui.
Vous n’avez pas besoin de construire toutes ces fonctionnalités aujourd’hui.
Mais vous devez éviter de prendre aujourd’hui des décisions qui rendront inutilement difficiles les évolutions de demain.
J’explique souvent cela à mes clients avec une analogie architecturale.
Le frontend est ce que les visiteurs voient.
Ce sont les murs, les fenêtres, les portes, l’éclairage et la décoration.
Le backend correspond davantage aux fondations, à la plomberie, à l’électricité et à la structure du bâtiment.
Vous pouvez relativement facilement repeindre un mur.
Modifier les fondations est une autre histoire.
Il en va de même pour un logiciel.
Changer un bouton est facile.
Modifier toute l’architecture d’une base de données après que des milliers d’utilisateurs et d’enregistrements en dépendent ne l’est pas.
Changer une couleur est facile.
Modifier l’authentification et les autorisations dans toute une application ne l’est pas.
Changer un titre est facile.
Modifier l’architecture de contenu d’un grand site multilingue ne l’est pas.
C’est pourquoi, lorsque je travaille sur un projet, je préfère généralement comprendre le backend avant de passer trop de temps à perfectionner le frontend.
Nous devons savoir ce que nous construisons avant de décider comment le décorer.
Parfois, absolument.
Je ne pense pas que les entreprises doivent arrêter d’utiliser les générateurs de sites web basés sur l’IA.
Au contraire, je pense qu’ils sont extrêmement utiles.
Si vous êtes un fondateur non technique et que vous avez une idée, un générateur basé sur l’IA peut être une excellente manière de transformer cette idée en quelque chose de concret.
Vous pouvez prototyper.
Vous pouvez tester une idée.
Vous pouvez la montrer à des investisseurs.
Vous pouvez communiquer votre vision à un développeur.
Vous pouvez découvrir ce que vous voulez réellement.
Vous pouvez même construire un véritable produit avec ces outils.
La question ne devrait donc pas être :
« Est-ce que cet outil d’IA est mauvais ? »
La meilleure question est :
« Est-ce que la manière dont je l’utilise est adaptée à mon entreprise ? »
Pour une simple landing page ?
Probablement très bien.
Pour un MVP temporaire ?
Potentiellement excellent.
Pour valider une idée ?
Absolument.
Pour un petit outil interne ?
Cela peut être très utile.
Pour une plateforme critique pour l’entreprise, qui doit évoluer pendant les dix prochaines années ?
Là, il faut réfléchir beaucoup plus sérieusement.
Pas parce que l’IA est incapable de la construire.
Mais parce que quelqu’un doit toujours en concevoir l’architecture.
Elle change leur rôle.
C’est une distinction importante.
L’avenir n’est pas nécessairement :
Les humains écrivent chaque ligne de code manuellement.
Il ressemble de plus en plus à ceci :
Les humains définissent le système et l’IA aide à le construire.
Un développeur peut passer moins de temps à écrire manuellement du code répétitif et davantage de temps à réfléchir à l’architecture, aux données, à la sécurité, à la logique métier, aux tests, aux performances et aux décisions produit.
Et c’est une bonne chose.
Je ne veux pas passer trois heures à écrire du code répétitif si une IA peut le faire en trois minutes.
Je préfère utiliser ces trois heures pour comprendre l’entreprise.
C’est là que se trouve la véritable valeur.
C’est ainsi que je vois personnellement le développement assisté par l’IA.
Le développeur apporte :
La compréhension du métier
Quel problème essayons-nous réellement de résoudre ?
L’architecture
Comment le système doit-il être structuré ?
La modélisation des données
Quelles informations existent et comment sont-elles liées ?
Les choix technologiques
Quels outils et frameworks sont réellement adaptés ?
La sécurité
Qui peut accéder à quoi ?
La qualité
Le système se comporte-t-il réellement comme prévu ?
La vision à long terme
Comment ce système pourra-t-il évoluer ?
Et l’IA peut aider avec :
L’implémentation
Écrire le code.
L’exploration
Tester différentes approches.
Les tests
Générer et améliorer les tests.
Le debugging
Identifier les problèmes.
Le refactoring
Améliorer le code existant.
La documentation
Expliquer les systèmes et les décisions.
La vitesse
Passer beaucoup plus rapidement de l’idée à une implémentation fonctionnelle.
Cette combinaison est beaucoup plus puissante que l’une ou l’autre séparément.
L’une des plus grandes erreurs que je vois est de choisir une technologie uniquement en fonction de son prix actuel.
Une entreprise peut économiser de l’argent en choisissant la manière la plus rapide et la moins chère de lancer son site.
Et parfois, c’est exactement la bonne décision.
Mais parfois, le site le moins cher n’est que la première version la moins chère.
Si vous devez ensuite tout reconstruire, migrer vos contenus, repenser votre base de données, remplacer votre système d’authentification, changer d’hébergeur, recréer vos intégrations et réécrire votre logique métier, l’économie initiale peut finalement devenir très coûteuse.
Cela ne signifie pas que toutes les petites entreprises ont besoin d’une plateforme personnalisée et complexe.
Pas du tout.
Parfois, WordPress est exactement la bonne solution.
Parfois, un générateur de sites est exactement la bonne solution.
Parfois, un site statique est tout ce dont vous avez besoin.
Et parfois, une application personnalisée représente le bon investissement.
L’objectif n’est pas d’utiliser la technologie la plus chère.
L’objectif est d’utiliser l’architecture adaptée à votre entreprise et à son avenir.
Ma réponse est :
Oui.
Mais ne confondez pas utiliser l’IA avec laisser l’IA prendre toutes les décisions techniques à votre place.
Utilisez l’IA pour explorer.
Utilisez l’IA pour prototyper.
Utilisez l’IA pour aller plus vite.
Utilisez l’IA pour écrire du code.
Utilisez l’IA pour tester vos idées.
Utilisez l’IA pour améliorer votre processus de développement.
Mais si votre site web devient une partie importante de votre entreprise, comprenez ce qui se trouve dessous.
Sachez où sont vos données.
Sachez qui possède votre code.
Sachez quelle base de données vous utilisez.
Sachez de quels services votre application dépend.
Sachez comment fonctionne l’authentification.
Sachez ce qui se passe si vous quittez la plateforme.
Sachez comment votre site peut évoluer.
Sachez si votre architecture est capable de soutenir l’entreprise que vous souhaitez construire.
Parce que la phrase la plus dangereuse dans le développement logiciel n’est pas :
« Je ne sais pas comment cela fonctionne. »
C’est :
« Ça fonctionne, donc ça doit être correct. »
Vos clients ne se soucient pas de savoir si votre site a été créé par un développeur, une IA, WordPress, Next.js ou un générateur de sites basé sur l’IA.
Ils veulent simplement que ça fonctionne.
Votre entreprise, en revanche, devrait se demander ce qui se passera après que cela fonctionne.
C’est là que commence le véritable logiciel.
Chez Natasun, nous ne considérons pas l’IA comme l’ennemie du développement logiciel.
Nous la considérons comme un outil supplémentaire dans notre boîte à outils.
Notre approche consiste à combiner les pratiques modernes de développement avec le développement assisté par l’IA afin de créer des logiciels qui ne sont pas seulement beaux en surface, mais également solides dans leur structure.
L’objectif n’est pas simplement de lancer quelque chose.
L’objectif est de construire quelque chose qui puisse continuer à évoluer.
Parce que votre premier site web n’a peut-être besoin que d’une page d’accueil.
Mais votre entreprise pourrait un jour avoir besoin d’une plateforme complète.
Et idéalement, vos premières décisions techniques ne devraient pas vous empêcher d’y arriver.
