L'ère des logiciels personnels : des applications conçues pour vous et sept amis

Le logiciel grand public est une phase, pas un état permanent. Les vingt dernières années de SaaS grand public ont constitué une parenthèse temporaire due au coût élevé de la distribution, et cette parenthèse touche à sa fin.

Pour la première fois depuis les débuts de l'informatique, une seule personne peut développer une application fonctionnelle le dimanche pour neuf utilisateurs et la déployer avant la fin de la journée. Il ne s'agit pas d'un simple passe-temps. C'est un changement structurel qui concerne les développeurs de logiciels, leurs destinataires et la définition même du design.

Qu'est-ce qu'un logiciel personnel ?

Un logiciel personnel est un logiciel développé par une seule personne, souvent pour elle-même, parfois pour dix utilisateurs spécifiques, et presque jamais pour un marché. Il est conçu sur mesure, et non par hasard. Son créateur connaît chaque utilisateur par son nom.

Geoffrey Litt écrit depuis des années sur le concept de logiciel malléable, selon lequel les utilisateurs d'un outil devraient également pouvoir le modifier. Linus Lee conçoit de petits outils pour faciliter sa réflexion. Maggie Appleton a inventé l'expression « développeurs aux pieds nus » pour désigner la vague de personnes non-ingénieures capables de livrer des logiciels fonctionnels grâce à l'effondrement des coûts de développement.

En rassemblant ces éléments, on obtient une catégorie : des logiciels destinés à leur créateur et à un petit groupe d'amis, de membres de la famille ou de collègues, dont la valeur réside dans leur capacité à répondre aux besoins spécifiques de ce groupe restreint.

Pourquoi maintenant, et pourquoi pas en 2015 ?

Deux choses ont changé simultanément. Les assistants vocaux ont permis à une seule personne de créer une application fonctionnelle en un après-midi à un coût abordable. Parallèlement, les coûts de distribution, d'hébergement, de déploiement, de paiements et d'authentification ont atteint zéro ou presque.

En 2015, développer une application de niche impliquait six mois de travail acharné, une intégration Stripe de trois jours et une procédure de déploiement nécessitant une semaine de stabilisation. Ce modèle économique n'était pas viable pour les structures plus petites qu'une startup. Le potentiel des cas d'utilisation les plus courants était inaccessible.

En 2026, la même application se résume à une seule invite, un seul déploiement Vercel et un schéma Convex. Le public cible minimal pour un logiciel est passé de « plusieurs dizaines de milliers » à « vous et sept amis ». Il ne s'agit pas d'une simple amélioration technique, mais de l'ouverture d'une nouvelle catégorie.

Le troisième facteur est le goût. Toute une génération de concepteurs et de bidouilleurs a grandi avec les logiciels, s'est forgée des opinions bien arrêtées sur les défauts des applications qu'elle utilisait quotidiennement et a désormais les moyens de les corriger elle-même, sans demander la permission à personne.

Des exemples concrets, pas des hypothèses

Ceci n'est pas une expérience de pensée. De nombreux ordinateurs portables utilisent déjà des logiciels personnels.

Certaines personnes utilisent Notion comme un mini-CMS privé pour leur foyer, avec des vues et des modèles incompréhensibles pour les personnes extérieures à la famille. Les projets parallèles Replit et Lovable sont déployés en une soirée, utilisés par une dizaine de collègues, et gèrent discrètement les tâches importantes pendant des années. Agendas familiaux, générateurs de factures personnalisés, planificateurs de repas sur mesure (à la manière de food-plan-pi), tous destinés à un public de quatre à quinze personnes.

Le mouvement des logiciels flexibles produit des outils où l'utilisateur est aussi l'éditeur. Tana permet de construire ses propres systèmes d'information au lieu de se conformer à un modèle. Capacities propose une solution similaire. L'écosystème de plugins d'Obsidian constitue tout un ensemble d'outils personnels partagés entre personnes aux profils similaires.

Le modèle : un créateur, un public restreint, une solution parfaitement adaptée. Rien n'est déployé à grande échelle. Rien n'est commercialisé. Le logiciel existe, tout simplement, pour les personnes auxquelles il est destiné, et c'est là tout son intérêt.

En quoi est-ce différent du no-code ?

Le no-code utilisait des modèles. Les logiciels personnels sont des logiciels sur mesure. La différence réside dans l'intention.

Un outil sans code vous fournit un ensemble Lego et vous demande de construire une maison semblable à celle du catalogue. Le principe est simple : des milliers de personnes construiront des maisons similaires sur la même plateforme. La rentabilité repose sur ce modèle.

Les logiciels personnels partent d'une question différente. Il ne s'agit pas de choisir « quel modèle correspond à mes besoins », mais de se demander « de quoi ma situation réelle a-t-elle besoin et comment la coder ? ». Le créateur ne choisit pas parmi des options. Il décrit son intention, souvent en langage clair, à un assistant IA, et obtient un code parfaitement adapté.

C'est important, car les outils basés sur des modèles ont leurs limites. Tout ce qui ne correspond pas au modèle est modifié ou abandonné, contrairement aux outils sur mesure. Si votre comptabilité a besoin d'une colonne pour « le montant que Kyle reçoit ce mois-ci avec son taux fixe de 10 % », vous l'ajoutez simplement. Pas de demande auprès du fournisseur, pas de fonctionnalités en attente, pas de délai.

La longue traîne atteint enfin son point de non-retour

Chris Anderson a décrit le concept de la longue traîne en 2004, mais les logiciels n'en ont jamais vraiment profité. Le SaaS grand public pouvait s'avérer rentable pour le haut de gamme et le milieu de gamme. Au-delà, il s'agissait d'un désert de besoins insatisfaits ne justifiant pas la création d'une entreprise.

Les logiciels personnels comblent ce désert. Les cas d'usage qui n'ont jamais été assez importants pour soutenir une startup, les flux de travail de niche, les spécificités du quotidien, les outils pour équipes de six personnes, constituent désormais le terrain de prédilection des applications individuelles.

La donne a basculé. Un cas d'usage avec huit utilisateurs était auparavant irréalisable. Il est maintenant extrêmement facile à mettre en œuvre. Multipliez cela par un million de micro-niches et vous obtenez une économie du logiciel radicalement différente des classements de l'App Store.

Ce qui disparaît, ce qui survit, ce qui se développe

Le SaaS ne sera pas entièrement supplanté par les logiciels personnels. La transition est inégale, et les gagnants et les perdants sont prévisibles si l'on analyse où se situe réellement la valeur.

Ce qui disparaît en premier, c'est le SaaS grand public destiné à des cas d'usage de niche. Le segment « nous sommes le Notion des promeneurs de chiens ». Quiconque propose un produit légèrement spécialisé sur une plateforme générique se retrouve désormais en concurrence avec un dimanche après-midi et une invite de commande. Cette bataille se soldera par un résultat unique.

Ce qui survit et se développe, ce sont les plateformes, les composants de base et l'infrastructure. Convex, Vercel, Supabase, Stripe, Clerk, les fournisseurs d'IA, Replit, Lovable. La couche de base s'agrandit à mesure que le nombre de développeurs de logiciels augmente, au lieu de diminuer. Il en va de même pour les composants de base des systèmes de conception, les bibliothèques d'interface utilisateur, les ensembles d'icônes, les flux d'authentification que tout le monde réutilise.

Ce qui survit également, ce sont les véritables logiciels grand public, dont l'usage est véritablement universel : messagerie électronique, calendriers, navigateurs, systèmes d'exploitation, moteurs de recherche, réseaux sociaux. Les logiciels personnels ne remplacent pas WhatsApp. Ils remplacent l'outil de gestion de projet pour lequel une agence de quinze personnes payait huit cents dollars par mois.

SaaS grand public vs logiciel personnel : une comparaison directe

La différence est plus flagrante lorsqu’on compare les deux modèles.

| Dimension | SaaS grand public | Logiciel personnel |

|-----------|------------------|-------------------|

| Public cible | De plusieurs milliers à plusieurs millions | De une à quelques dizaines d’utilisateurs |

| Positionnement | « Pour les équipes qui font X » | « Pour moi et sept amis » |

| Distribution | Publicité payante, SEO, équipe commerciale | Partagée via une conversation de groupe |

| Tarification | Abonnement mensuel par utilisateur | Forfait, don ou gratuité entre amis |

| Priorité de conception | Prise en main rapide pour un nouvel utilisateur | Adaptation parfaite à un utilisateur connu |

| Personnalisation | Menu Paramètres, options de fonctionnalités | Modification du code source, intervention de l’IA |

| Durée de vie | Illimitée, avec des fonctionnalités supplémentaires régulières | Tant que le cas d’utilisation persiste, puis archivage |

| Incitation des développeurs | Conquérir un marché | Résoudre un problème spécifique |

Remarquez la ligne relative aux priorités de conception. C'est là que le rôle du concepteur évolue le plus.

Le nouveau rôle du concepteur

Si vous êtes concepteur, votre travail change. La conception pour le grand public consiste à faciliter l'intégration d'inconnus, à minimiser les frictions dans les pires situations et à ne jamais tenir compte du contexte. La conception de logiciels personnels, quant à elle, prend en compte le contexte, identifie les utilisateurs et optimise l'adéquation, et non la généralité.

Le nouveau travail de conception repose sur trois étapes clés : définir le contexte, exprimer son goût et peaufiner.

Définir le contexte consiste à fournir à un assistant IA ou à une petite équipe suffisamment d'informations sur les utilisateurs pour que le résultat soit pertinent. Il ne s'agit pas de « concevoir un planificateur de repas », mais de « concevoir un planificateur de repas pour une famille de quatre personnes, dont une végétarienne, dont les enfants n'aiment pas les textures et dont le cuisinier dispose de trente minutes en semaine ». Le cahier des charges constitue la conception.

Le goût est le filtre. Lorsque le code est peu coûteux et les invites gratuites, le principal obstacle est la qualité du résultat. Le rôle d'un designer est de savoir ce qui est esthétique pour un public spécifique et de rejeter tout ce qui ne correspond pas. Moins de dessin, plus de jugement.

L'édition, c'est l'itération. Un logiciel personnel n'est pas simplement confié à des ingénieurs pour être livré ; il est façonné au fil du temps, souvent en direct, par le designer qui est aussi le créateur ou qui travaille à ses côtés. Le fichier Figma n'est plus le produit final. C'est l'application en fonctionnement.

Comment concevoir pour un public de 10 personnes

Concevoir pour dix personnes n'est pas une version réduite de la conception pour dix mille. C'est une discipline différente. Voici sept principes qui restent valables.

1. Nommez chaque utilisateur. Dressez une liste. Sachez ce dont chaque personne a besoin, ce qu'elle déteste et ce qu'elle est prête à tolérer. Si vous ne pouvez pas rédiger ce document, vous concevez encore pour une abstraction.

2. Oubliez la formation initiale. Vos utilisateurs n'ont pas besoin d'une visite guidée, ce sont vos amis. Plongez-les directement dans l'application déjà configurée pour eux. Privilégiez la réponse à la question.

3. Optimisez pour le cas particulier, pas pour la moyenne. L'utilisateur moyen n'existe pas lorsqu'il y en a dix. Il y a juste Aaron, qui aime le mode sombre, et Serina, qui a besoin du raccourci clavier. Chacun obtient ce qu'il veut.

4. Laissez place à l'imperfection là où c'est nécessaire. Un logiciel personnel n'a pas besoin d'un site marketing, d'une page de prix ou d'une illustration principale. L'écran d'accueil peut être une liste, les paramètres un fichier JSON. Investissez votre style là où il est apprécié, pas là où il est attendu.

5. Rendez-le modifiable. Vos utilisateurs voudront apporter des modifications. Concevez de manière à ce que ces modifications soient faciles, même si cela signifie une interface légèrement moins soignée. La flexibilité est plus importante que la perfection à cette échelle.

6. Concevez pour un seul appareil, pas pour tous. Si votre public utilise l'application sur un ordinateur portable, ignorez la version mobile. S'il l'utilise sur un téléphone, ignorez la version de bureau. La conception universelle et adaptative est une approche marketing de masse.

7. Pensez à l'archivage, pas à l'éternité. Ce logiciel n'a pas besoin de durer éternellement. Il doit fonctionner aussi longtemps que son utilité le justifie. Une fois son utilité terminée, archivez-le sans cérémonie.

La vague des développeurs minimalistes

L'expression « développeurs minimalistes » de Maggie Appleton met en lumière un aspect que l'industrie a longtemps négligé. La prochaine génération de développeurs n'est pas composée d'ingénieurs ayant appris à concevoir. Il s'agit de concepteurs, de rédacteurs, de chercheurs, de comptables, d'enseignants et d'opérateurs ayant appris à déployer des applications.

Ces personnes n'auraient jamais pu décrocher un poste d'ingénieur très bien rémunéré par une formation intensive. Elles ont un emploi, une vie et des problèmes spécifiques à résoudre. Désormais, elles sont capables de décrire leurs besoins en langage clair, d'obtenir un code fonctionnel et de l'exécuter sur un ordinateur portable ou via une plateforme gratuite.

Ce sont principalement ces personnes qui développent les logiciels personnels. Pas des fondateurs à temps plein. Des personnes possédant une solide expertise métier, des compétences techniques limitées et la patience d'itérer avec un assistant IA jusqu'à obtenir un résultat satisfaisant. Le résultat ? Des logiciels conçus par des personnes qui comprennent réellement le problème, une catégorie de logiciels qui a cruellement manqué à l'industrie.

Conséquence : le goût en matière de design des logiciels personnels est généralement plus exigeant que celui des SaaS grand public. Le développeur n'est pas un chef de produit junior avec une feuille de route à défendre ; c'est la personne qui vit le problème au quotidien. Dès qu'il repère un défaut ou une anomalie, il le corrige immédiatement. Le cycle de rétroaction est si court qu'une mauvaise conception ne survit littéralement pas à un week-end.

Qu'est-ce qui change dans le développement logiciel ?

Quand le public est restreint et que le développeur est proche de ses utilisateurs, le développement logiciel évolue. Les paramètres par défaut changent. Les compromis se font différemment.

La fiabilité est moins exigeante. Si l'application dysfonctionne pour dix personnes, le développeur en est informé par une discussion de groupe et corrige le problème. Il n'y a ni SLA, ni astreinte, ni procédure d'escalade. Cela peut paraître problématique, mais il faut comprendre que la prétendue fiabilité des SaaS grand public est surtout un fardeau pour l'utilisateur.

La personnalisation devient la norme plutôt qu'une option. Dans les logiciels grand public, la personnalisation se résume à un menu de paramètres, une liste d'options ajoutées à contrecœur par le développeur, tandis que dans les logiciels personnels, elle est au cœur même du système. Si vous souhaitez ajouter une colonne, le développeur l'ajoute ; si vous voulez changer les couleurs, il les change. Le produit n'est pas figé et n'est pas renégocié trimestriellement.

La documentation est différente. Le fichier README d'un outil utilisé par dix personnes se résume à un paragraphe de contexte, une capture d'écran et le numéro de téléphone du développeur. La base de connaissances de trente pages, la visite guidée intégrée, les articles d'aide, le widget de chat : tout cela représente un superflu pour un public restreint.

Les choix en matière de performances évoluent. Vous pouvez déployer une application moins performante pour dix utilisateurs de confiance, car ils vous signaleront tout problème. Impossible de déployer une application lente auprès d'un million d'inconnus. Les logiciels personnels s'affranchissent de nombreuses optimisations prématurées.

Conséquences pour l'éthique, les portefeuilles et la tarification

Les logiciels personnels soulèvent des questions essentielles concernant la propriété des données, la dépendance vis-à-vis du client et la pérennité du logiciel. Les réponses sont généralement plus pertinentes que celles offertes par le SaaS. Les données restent là où vous les stockez, souvent dans votre propre base de données ou un fichier que vous contrôlez. La dépendance vis-à-vis du client est moindre car le créateur est directement impliqué, contrairement à un fournisseur qui a intérêt à vous retenir.

La pérennité est le point le plus délicat. Un logiciel personnel disparaît lorsque son créateur cesse de le maintenir, ce qui arrive. En réalité, c'est acceptable. La plupart des logiciels ne sont pas conçus pour durer éternellement, et le compromis pour une utilisation adaptée et une propriété exclusive est d'accepter que l'application puisse fonctionner pendant deux ans avant de disparaître.

Le modèle de tarification évolue car l'unité de valeur change. Les abonnements mensuels par utilisateur supposent un marché. Les logiciels personnels ont des clients, et non des consommateurs, et ces clients paient différemment.

Frais fixes par projet, contrats de maintenance pour les modifications continues, système de partage entre amis, rémunération à la performance pour des fonctionnalités spécifiques. Le créateur ne propose pas de solution SaaS. Il gère un petit atelier sur mesure ou développe des applications gratuitement pour ses proches. Ces deux approches sont aujourd'hui économiquement viables.

Pour les designers qui vendent leurs services, l'évolution consiste à passer de la conception d'un système pour le lancement d'un SaaS à la conception et au développement d'un outil sur mesure pour une équipe ou une famille. Le livrable est l'application fonctionnelle, et non le fichier Figma. La tarification est basée sur la valeur du problème résolu, et non sur le nombre d'heures facturées.

Dans les portfolios, le travail paraîtra plus atypique. Moins de sites marketing léchés, plus de captures d'écran d'outils internes originaux qui résolvent de vrais problèmes pour de vrais groupes. L'étude de cas ne sera plus « nous avons repensé un tableau de bord pour une startup en levée de fonds de série B », mais plutôt « nous avons créé un outil d'organisation de sorties scolaires pour trente parents, et il a été réellement utilisé ».

Ce que les designers devraient faire cette année

Le changement est inévitable. Voici à quoi ressemblera la stratégie gagnante en 2026.

Commencez par créer pour vous-même. Choisissez un problème que vous rencontrez réellement, dans votre vie personnelle ou professionnelle, et créez l'outil avec Replit, Lovable, Cursor, ou simplement Claude Code et un compte Vercel. L'objectif n'est pas d'apprendre à utiliser les outils, mais de ressentir ce que c'est que d'être toute l'équipe sur un projet logiciel.

Commencez par créer pour dix personnes de votre entourage. Après un outil personnel, créez-en un pour un petit groupe : votre famille, un club, votre équipe au travail. Observez comment vos choix de conception évoluent lorsque vous connaissez chaque utilisateur par son nom.

Cessez de concevoir vos projets en fonction des exigences du grand public. Repositionnez-vous. Le marché n'achète plus une simple « intégration sans friction pour un large public ». Il achète « l'adéquation, le bon goût et la capacité de livrer le produit ». Démontrez-le dans votre portfolio.

Suivez les écrits sur les logiciels flexibles. Litt, Lee, Appleton, la communauté Ink and Switch, les développeurs de petits outils sur Twitter et Threads. Le vocabulaire, les modèles et le langage de conception des logiciels personnels se forgent actuellement au sein de ces échanges. Maîtrisez-les.

L'ère des logiciels personnels est l'événement le plus marquant de ces quinze dernières années en matière de conception logicielle. Les SaaS grand public continueront d'exister dans les catégories où ils sont pertinents. Mais le marché de niche vient de s'ouvrir, et ceux qui s'y implanteront en premier définiront ce que signifie concevoir pour un public de dix personnes. Soyez parmi eux.

hero: key: hero prompt: "Voxel illustration. A small house-sized app glowing warmly, with 10 little floating screens around it, each tailored to a different person. Soft pastel. Editorial. The composition does not include any human figures." alt: "Voxel illustration of a small house-sized app glowing warmly with ten tiny tailored screens floating around it" width: 1600 height: 900 inline-1: key: mass-vs-personal prompt: "Voxel split illustration: left, a giant generic SaaS dashboard. Right, ten tiny bespoke apps, each warm and specific. Soft pastel. The composition does not include any human figures." alt: "Voxel split image showing one giant generic SaaS dashboard on the left and ten tiny bespoke apps on the right" width: 1400 height: 900 inline-2: key: distribution-collapse prompt: "Voxel illustration showing a long-tail curve labeled 'use cases' with tiny apps populating the previously-empty tail. Soft pastel." alt: "Voxel long-tail curve labeled use cases with tiny apps filling the previously empty tail" width: 1400 height: 900 inline-3: key: design-for-ten prompt: "Voxel illustration of a designer's workspace tuned for an audience of 10: name tags on the wall, context notes, an obvious local fit. Soft pastel. The composition does not include any human figures." alt: "Voxel designer workspace with name tags and context notes tuned for an audience of ten" width: 1400 height: 900 inline-4: key: what-dies-what-survives prompt: "Voxel illustration: on one side, generic SaaS dashboards crumbling into mist. On the other, infrastructure platforms growing taller. Soft pastel. The composition does not include any human figures." alt: "Voxel illustration of generic SaaS dashboards crumbling on one side and infrastructure platforms growing on the other" width: 1400 height: 900