Les 5 types de logiciels que tu peux créer avec l'IA

TL;DR — Pas toutes les idées n'ont leur place dans un App Store. La plupart des produits dont tu as vraiment besoin entrent dans exactement cinq catégories techniques : un outil local, une application web, une application native, un service d'arrière-plan ou un projet matériel (hardware). Identifier la bonne forme te fait gagner des mois de développement hasardeux et détermine si tu peux te lancer en une demi-heure avec un constructeur d'IA hébergé ou si tu dois combiner un agent de codage avec Supabase et Vercel. Pour les solopreneurs francophones, l'application web est, dans la plupart des cas, la meilleure première étape — le reste est plus rare, mais parfois incontournable.

Le problème : Tu sais ce que tu veux, mais pas comment l'obtenir

La plupart des gens qui s'essaient aux constructeurs d'IA (AI builders) ne bloquent pas sur le code. Ils bloquent à cause de la confusion sur le point de départ. Ils savent à peu près ce qu'ils veulent améliorer — un tableau Excel peu fiable, un processus qui doit être réexpliqué chaque trimestre, une info qui existe en direct quelque part mais n'arrive nulle part. Mais de là à savoir si cela doit être un script, un site web ou un petit appareil, c'est le grand flou.

C'est exactement là que commence le vrai travail : décrire le changement souhaité de manière à en déduire la forme technique — avant même qu'un modèle n'écrive une seule ligne de code. Dans une vidéo très commentée sur YouTube, cela est illustré par deux projets : un tracker de ferrys à Amsterdam, qui écoute le signal radio AIS des navires (obligatoire par la loi) avec un Raspberry Pi, une antenne et un récepteur pour environ 200 euros, afin d'arriver enfin à l'heure à l'embarcadère ; et une application d'entretien de maison, conçue pour un seul et unique appartement — ses appareils, ses plantes, son jardin — qui génère automatiquement chaque semaine les tâches d'entretien à effectuer.

Aucun des deux n'est un logiciel « sophistiqué » (fancy). Ils sont petits, spécialisés et s'intègrent dans la vie d'une seule personne, contrairement à ce que ferait une application grand public. C'est le cœur du Personal Software (logiciel personnel) — et c'est exactement pour cela que tu as besoin d'une carte des cinq formes.

Le point de départ : Cinq questions avant le premier code

Avant de choisir un outil, réponds à ces cinq questions. Elles déterminent la forme bien plus que n'importe quel choix de modèle IA :

• Quel changement souhaites-tu ? Pas « une application », mais : qu'est-ce qui doit être ressenti différemment et de manière mesurable pour toi ?
• D'où vient le signal ? L'information se trouve-t-elle dans le monde réel (radio, capteur, caméra), dans un fichier, dans une API — ou seulement dans ta tête ?
• Où le résultat doit-il apparaître ? Sur un téléphone, sur un écran de bureau, sur un affichage dans la cuisine, ou nulle part (invisible) ?
• Qui peut voir et modifier ? Seulement toi ? Un partenaire ? Une équipe ? Cela détermine si tu as besoin d'une connexion (login) et de permissions.
• Que se passe-t-il en cas de panne ? Est-ce désagréable mais inoffensif — ou vraiment critique pour la sécurité ? Cela fait massivement varier la charge de travail.

Ces questions donnent déjà presque la réponse : un projet qui reçoit un signal physique et affiche le résultat localement sera un projet matériel. Un projet où deux personnes doivent maintenir la même liste synchronisée sur deux téléphones est une application web avec une base de données partagée.

Aperçu des cinq formes

1. L'outil local : L'itinéraire le plus simple

Un outil local fonctionne sur un seul ordinateur et utilise des fichiers ou une petite base de données locale (généralement SQLite). C'est la voie la plus simple pour tout ce que toi seul utilises — un organisateur de documents, un outil de recherche privé, un utilitaire pour renommer et trier mille photos. Il n'y a pas besoin de site web, de login ou d'hébergement. Tu dis en gros à l'agent de codage : « Installe-toi sur mon ordinateur portable et construis ça » — et c'est tout.

Quand le choisir : Si l'information reste privée, vit sur une seule machine et qu'aucune autre personne n'aura jamais besoin d'y accéder. Toute infrastructure Cloud serait alors une perte de temps et de ressources.

2. L'application Web : Ton option par défaut pour le Personal Software

L'application Web s'ouvre depuis un lien, fonctionne dans le navigateur et peut être ajoutée à l'écran d'accueil du téléphone. C'est l'option par défaut recommandée pour la plupart des projets personnels, à moins que tu aies une raison précise de rendre les choses plus complexes. Une seule version fonctionne sur ordinateur portable, iPhone et Android. Tu peux la partager avec des partenaires ou des collègues sans passer par un App Store ni devoir te procurer un compte « développeur » chez Apple.

L'architecture typique pour ce type d'application est simple : un backend partagé Supabase (Base de données Postgres + Login + Stockage de fichiers), l'application web devant, et Vercel comme hébergeur qui te fournit des liens d'aperçu avant de publier la version live. C'est cette combinaison — application Web + base de données partagée + hébergeur — qui rend l'exemple de l'entretien de la maison possible : deux personnes voient la même liste à jour sur deux téléphones différents.

Important lors du choix de la base de données : Les constructeurs hébergés (Hosted Builders) comme Lovable te demanderont plus tard si les données doivent résider dans leur propre backend Cloud géré ou dans Supabase. Leur propre Cloud est le chemin le plus court ; Supabase demande un peu plus de configuration, mais maintient la base de données et l'authentification dans un standard Postgres très utilisé — ce qui sauve ta portabilité. La règle d'or : Change l'interface tôt, pas les données. Déménager une application des années plus tard est beaucoup plus difficile que de créer une nouvelle interface par-dessus.

3. L'application Native : Seulement si le téléphone en demande plus

C'est ce que la plupart des gens entendent par « application » — Apple nous a habitués à ce mot depuis des années. Mais cela demande plus de travail. Tu n'en as besoin que si ton produit repose sur une fonctionnalité profonde du téléphone : des notifications Push fiables, le Bluetooth, la localisation en arrière-plan, le NFC ou une distribution exclusive via l'App Store. Sinon, ne te jette pas à l'eau.

La méthode la plus pratique est d'utiliser un agent de codage avec Expo : à partir d'un seul projet, on obtient une application iOS et Android, et un service de build gère la majeure partie de la signature et de l'empaquetage. Tu auras tout de même besoin de comptes développeurs Apple et Google, et tu devras passer leurs évaluations (reviews) — c'est une vraie procédure, un peu lourde. C'est pourquoi la règle est : Prouve d'abord ton idée sous forme d'application web privée, à moins que les capacités matérielles du téléphone soient indissociables de ton concept. Tu ne veux pas payer la « taxe » de l'App Store juste pour découvrir si ton partenaire aime ou non la liste d'entretien.

4. Le service d'arrière-plan : Le logiciel sans écran

Un service d'arrière-plan n'a parfois aucune interface utilisateur (UI). Il se réveille — selon un planning ou suite à un événement —, accomplit sa tâche et envoie le résultat quelque part. Il vérifie un jeu de données public chaque matin, traite un fichier dès sa réception ou envoie une alerte si un capteur dépasse un seuil. Au fond, c'est une étape de transformation : prendre des données d'une source et les livrer à une destination. Ces services n'ont souvent pas besoin de ressembler à un « produit », mais nécessitent une logique de déclenchement propre et un endroit où atterrit le résultat (E-mail, Chat, Base de données).

5. Le projet matériel : Le logiciel au plus près du monde réel

Ici, le logiciel vit au plus près du monde physique : le récepteur AIS pour les ferrys, un écran sur la table de la cuisine, une caméra, un capteur d'usine. Le choix du mini-ordinateur dépend de la tâche :

• Raspberry Pi — un petit ordinateur polyvalent, idéal si un récepteur ou une antenne a besoin d'un décodeur tournant en continu.
• ESP32 — parfait si la tâche se résume presque exclusivement à « lire un capteur » ou « allumer un appareil ».
• Home Assistant — l'approche la plus rapide si les appareils existent déjà dans la maison et que tu veux juste les centraliser à un seul endroit.

Le levier décisif : plus tu te rapproches des capteurs existants d'une maison intelligente (Smart Home) standard, moins tu as besoin de construire toi-même et plus tu peux te contenter de câbler des composants prêts à l'emploi. Et parce que les agents de codage modernes peuvent désormais lire des photos de circuits imprimés et de composants, identifier les connexions, expliquer les broches (pins) et vérifier ton installation, la frontière entre le monde du logiciel et celui du matériel est plus poreuse que jamais.

Les deux voies : Constructeur hébergé vs Agent de codage

Une fois la forme choisie, les décisions d'outils deviennent presque triviales. Tu as essentiellement deux grandes familles :

Le constructeur hébergé (Hosted Builder comme Lovable, Replit, Bolt) est le chemin le plus rapide pour ta toute première application Web : tu décris le logiciel, le constructeur crée le projet, te montre un aperçu et te donne un bouton pour publier. Tu n'installes pas de langage de programmation, tu ne lances pas de serveur, tu n'as même pas besoin de comprendre la ligne de commande — et tu as quand même quelque chose de fonctionnel. Si le projet nécessite plus qu'une interface web (scripting Python, serveur tournant en continu, tâches planifiées, build mobile), Replit est le candidat le plus fort car il intègre davantage d'infrastructure dans son service. Bolt est une autre excellente option pour une application web Full-Stack rapide.

L'agent de codage (Coding-Agent) est l'étape suivante — et ce n'est pas réservé qu'aux experts : Codex ou Claude Code voient les fichiers de ton projet, les modifient, lancent l'application localement, lisent les erreurs et réessaient. Ajoute à cela GitHub Desktop pour un contrôle de version visuel, Supabase pour la base de données partagée et Vercel pour l'étape de publication. Le grand avantage : Tu peux remplacer un composant sans tout remplacer. Le modèle d'IA peut changer pendant que la base de données reste. L'hébergeur peut changer pendant que le code reste. L'interface peut évoluer sans bouger les données — c'est simplement une fenêtre différente donnant sur la même pièce.

Modèle ≠ Agent de codage ≠ Constructeur — et pourquoi c'est important

Les gens comparent souvent ces trois éléments comme s'il s'agissait du même produit. Ce n'est pas le cas. La superposition (stack) est claire :

• Le modèle est la couche pure de réflexion et de capacité de codage.
• L'agent de codage donne au modèle l'accès à un dossier, à des commandes, à des aperçus et à des outils.
• Le constructeur hébergé (Builder) package l'agent + l'environnement + le bouton de publication en un seul produit.

De cette stratification découle une grande liberté : Le modèle et l'environnement de travail n'ont pas besoin de provenir de la même entreprise. Tu peux utiliser un modèle ouvert comme GLM 5.2/5.3 via un écosystème d'outils de codage compatible. Pour ton tout premier build : Choisis un environnement, pas trois. La vraie liberté ne vient pas du fait de laisser trois modèles se disputer chaque bouton, mais du fait que tu possèdes les fichiers du projet, les données et les décisions — et que tu sais ce que le modèle fait.

Comment garder le modèle sur la bonne voie : Quatre petits fichiers

L'erreur la plus fréquente lors de la création avec l'IA n'est pas liée au code, mais aux décisions cachées. Soudain, le modèle choisit une base de données familière sans explication, ajoute un service payant ou rend l'application publique. La solution n'est pas de créer un prompt magique interminable — c'est un changement de rôle : Le modèle agit comme un partenaire de construction qui doit justifier ses décisions. Concrètement, cela signifie conserver quatre petits fichiers texte à côté du projet, que n'importe quel modèle peut lire :

• project.md — pour qui est le logiciel, ce qui se passe aujourd'hui, ce qui devrait se passer à la place (Avant/Après), où il doit tourner et quelles informations doivent rester privées.
• decisions.md — à chaque fois que le modèle fait un choix qui impacte les coûts, les données, l'accès, le déploiement ou la portabilité, il y consigne les options, la recommandation et la justification — en particulier si la décision a été prise avec toi.
• scenarios.md — les situations réelles que le logiciel doit gérer (par ex. « Créer un appareil via une photo sur téléphone, trouver le manuel correspondant, générer la prochaine tâche d'entretien »). Ces cas réels sont tes cas de test (test cases).
• agent.md / claude.md — le petit fichier d'instructions pour l'agent de codage respectif. Il indique seulement comment l'outil actuel doit se comporter ; les vérités fondamentales du projet restent dans les trois premiers fichiers.

# agent.md
Tu agis comme un partenaire de construction qui doit justifier ses décisions.
Si un choix affecte les coûts, les données, la confidentialité, la portabilité, le déploiement
ou la maintenance : explique-le en langage simple.
- Donne 2 à 3 options réalistes.
- Recommandation : choisis-en une pour ce projet et justifie-la.
- Précise ce qui sera plus facile / plus difficile à changer par la suite.
- Demande l'autorisation avant toute action publique, coûteuse ou destructive.
- Aucun secret (API keys) dans le code, les captures d'écran ou les chats.

# project.md (Exemple)
Objectif : Application d'entretien pour un seul appartement.
Avant : Rappels sur des Post-its, pas de vision commune.
Après : Les deux partenaires voient la même liste sur deux téléphones.
Exécution : Dans le navigateur, privé, seulement 2 logins.
Privé : Numéros de série, photos, liens vers les manuels.

Sécurité : privé avant public, contrôle en back-end

Les règles de sécurité semblent nombreuses, mais elles sont simples :

• Privé par défaut. Ne rends l'application publique que si tu as vraiment besoin d'un accès public — et utilise alors un système de login géré (Managed-Login). N'invente pas ton propre système de stockage de mots de passe, cela existe déjà.
• Les secrets restent dehors. Les clés API (API-Keys) et les mots de passe doivent aller dans les paramètres de secrets de ton hébergeur (par ex. Vercel), pas dans le code visible, les captures d'écran, les transcriptions de chat ou sur GitHub.
• Contrôle d'accès dans le backend, pas dans l'UI. « Masquer un bouton » n'est pas un contrôle de permission. Le fait que ton foyer ne puisse pas lire les données d'un autre foyer doit être imposé au niveau de la base de données. Supabase est très fort pour ça — et c'est exactement l'erreur la plus fréquente et la plus grave lorsque deux foyers utilisent le même produit.
• Prouver la sauvegarde et la restauration. Si les données sont importantes : fais une sauvegarde (backup) et teste la restauration. En cas de paiements, d'informations sur des enfants, de données médicales ou légales : fais auditer le logiciel avant de l'utiliser.
• Ne commence pas par le sensible. Commence par des choses simples et passe à des applications plus sécurisées à mesure que ton profil de risque évolue.

Tests : Pas de « terminé » sans une vraie validation pratique

Tu n'as pas besoin de vocabulaire de test (TDD, Unit tests, etc.) au début. Tu as besoin des situations qui te concernent, mises par écrit — puis de les tester sur l'appareil où le logiciel fonctionnera réellement, pour voir si ça marche. Pour l'exemple de la maison, cela signifie : Puis-je photographier un appareil et créer la bonne fiche ? Le numéro de modèle est-il conservé ? Ma partenaire voit-elle la même liste ? Que se passe-t-il si la photo est illisible ? Teste aussi les parcours d'échec (unhappy paths).

Et la phrase la plus importante : Rien ne remplace un humain disant : Ça fonctionne vraiment. Tu ne peux pas simplement demander à Lovable, Codex ou Claude Code de « tester si tout fonctionne » et leur faire confiance aveuglément. Le modèle livre un résultat, pas une garantie.

Ta première heure — voici comment commencer

Si tu veux te lancer maintenant :

1. Note la chose que tu as toujours voulu construire depuis des années.
2. Décris à quoi cela ressemble aujourd'hui et à quoi cela devrait ressembler à la place.
3. Identifie le signal ou l'information qui rend cela possible.
4. Détermine où le résultat doit apparaître (quel écran, pourquoi) et qui a le droit de le voir.
5. Demande-toi : Quelles seraient les conséquences si ça plante ?

Ensuite, reviens en arrière et choisis ta forme de construction. Pour la toute première application Web privée avec une configuration minimale : Lovable — avec le Cloud géré, sauf si tu sais que la portabilité de tes données est prioritaire (dans ce cas, Supabase dès le jour 1). Si tu veux plus de contrôle, ouvre Codex ou Claude Code. S'il y a un capteur impliqué : Raspberry Pi, Home Assistant ou ESP32 — et laisse l'agent de codage travailler sur le câblage.

Conclusion : La forme fait la moitié du travail

La couche que la plupart des gens ratent n'est pas le modèle ni le constructeur — c'est la question cruciale avant le premier code : dans laquelle des cinq formes s'inscrit ton besoin ? Une fois la forme définie, les décisions d'outils deviennent presque évidentes, les questions de sécurité sont claires, et le premier build est réalisable en quelques heures au lieu de plusieurs mois. L'ère du Personal Software n'appartient plus seulement aux techniciens qui vivent près des produits — elle appartient aux gens qui vivent près de leurs propres problèmes. Et ce sont précisément eux qui savent le mieux ce qui leur manque.

FAQ

Ai-je vraiment besoin d'une application Web pour un logiciel personnel ?

Pas automatiquement — mais l'application Web est dans la plupart des cas le point de départ le plus rapide, le moins cher et le plus portable, car une seule version fonctionne sur ordinateur et téléphone et peut être partagée sans passer par un App Store. Utilise un outil local si les données peuvent rester privées sur une seule machine, et une application Native uniquement si tu as vraiment besoin de fonctions profondes du téléphone comme les notifications Push, le Bluetooth, la localisation en arrière-plan ou le NFC. Si tu as un doute : commence par l'application Web et valide l'idée avant de t'engager dans les processus des App Stores et leurs coûts.

Quelle est la différence entre un agent de codage et un constructeur hébergé (Hosted Builder) ?

L'agent de codage (ex. Codex, Claude Code) travaille dans tes propres fichiers de projet, voit les erreurs, lance l'application localement et modifie le code, tandis que le constructeur hébergé (Lovable, Replit, Bolt) regroupe l'environnement, la base de données, l'authentification et la publication dans un seul service. La conséquence pratique : avec l'agent, chaque composant reste interchangeable — le modèle, l'hébergeur et l'interface peuvent changer indépendamment tandis que les données restent en place. Avec le constructeur hébergé, tu obtiens le chemin le plus court de la description à l'interface, mais tu paies le prix d'une plus grande dépendance à la plateforme.

Comment empêcher le modèle de prendre des décisions surprenantes à mon insu ?

Change son rôle : le modèle doit agir comme un partenaire de construction qui justifie ses décisions, au lieu de les cacher silencieusement dans le code. Concrètement, tu maintiens quatre petits fichiers — project.md (objectif, avant/après, confidentialité), decisions.md (chaque choix avec coûts/données/déploiement + justification), scenarios.md (tes vrais cas de test) et agent.md/claude.md (règles de comportement pour l'outil actuel) — et tu exiges que le modèle propose deux ou trois options pour tout choix important, en recommande une, et te demande l'autorisation avant toute action publique, coûteuse ou destructrice.

Une application Native vaut-elle la peine pour un outil interne ?

Pour un outil interne, c'est surdimensionné dans la grande majorité des cas, car les évaluations de l'App Store, les comptes développeurs Apple/Google et la signature des applications impliquent des procédures lourdes dont tu ne devrais pas avoir besoin. Une application Web dans le navigateur ou un build interne Expo pour la famille couvre les mêmes cas d'usage, sans les frictions des Stores. Ne choisis une application Native que si ton produit est fonctionnellement lié à une capacité matérielle du téléphone dont on ne peut se passer — sinon, l'application Web remplira la même fonction pour une fraction de l'effort.

Comment m'assurer que deux foyers ne voient pas les données l'un de l'autre dans la même application ?

Le contrôle d'accès doit se faire en backend, pas dans l'interface — masquer un bouton n'est pas une vraie restriction. Impose cette frontière dans la base de données (avec Supabase, utilise le Row-Level-Security ou des mécanismes équivalents), de sorte qu'une connexion (login) ne puisse lire ou modifier que les données de son propre foyer, et ajoute cette limite comme l'un des cas dans tes tests scenarios.md. Évite également de confondre l'erreur « ça a l'air fini » avec « c'est sécurisé » : vérifie activement qu'un second foyer ne peut pas voir les données du premier avant de déployer le produit à plusieurs parties.

Puis-je utiliser un modèle ouvert comme GLM dans un outil de codage ?

Oui — le modèle et l'environnement de travail n'ont pas besoin de provenir de la même entreprise, et c'est l'une des plus grandes libertés de l'outillage IA actuel. Tu peux utiliser un modèle ouvert comme GLM 5.2 ou 5.3 via un stack d'outils de codage compatible avec une clé API, tout en gardant le contrôle sur ton environnement, tes données et ton déploiement. Pour le tout premier build, je recommande tout de même de choisir un seul environnement plutôt que d'entasser plusieurs modèles dans un projet — la liberté vient de la propriété des fichiers et des données, pas de l'utilisation simultanée de trois agents.

Sources

• Vidéo détaillant systématiquement les cinq formes de logiciels : « Nobody Laid Out The Five Kinds Of Software You Can Make. So I Did. » — https://www.youtube.com/watch?v=joRXo6x7Pgk
• Lovable (constructeur d'IA hébergé pour applications web) : https://lovable.dev
• Replit (constructeur avec une infrastructure forte) : https://replit.com
• Bolt (applications web Full-Stack rapides) : https://bolt.new
• Supabase (Postgres + Auth + Stockage) : https://supabase.com
• Vercel (Hébergement & Liens d'aperçu) : https://vercel.com
• GitHub Desktop (contrôle de version visuel) : https://desktop.github.com
• Raspberry Pi (petit ordinateur tout usage) : https://www.raspberrypi.com
• ESP32 (appareil pour capteur unique) : https://www.espressif.com
• Home Assistant (connexion centrale des appareils de la maison existants) : https://www.home-assistant.io
• Expo (un seul projet → iOS + Android) : https://expo.dev
• Codex (agent de codage) : https://openai.com/index/introducing-codex/
• Claude Code (agent de codage) : https://www.anthropic.com/claude-code
• GLM 5.2 / 5.3 (modèles ouverts de Z.ai) : https://z.ai
• SQLite (base de données locale) : https://sqlite.org