Types d'applications : web, API, mobile, service, desktop

On ne construit pas un entrepôt comme un immeuble de bureaux

Sur Le Chantier, la première décision qui engage tout le reste n'est ni le béton ni le planning. C'est le type d'ouvrage.

Un immeuble de bureaux, un entrepôt logistique, un parking silo et une passerelle piétonne partent tous d'un terrain, de charges admissibles et d'un budget. Ensuite, plus rien ne se ressemble : portée des planchers, hauteur libre, largeur des circulations, issues de secours, quais de livraison, raccordements. Le maître d'œuvre ne choisit pas cette forme au feeling, il la déduit du programme et de l'étude de sol.

En logiciel, la même marche existe, et beaucoup d'équipes l'enjambent sans la voir. On débat du framework front avant d'avoir décidé si le besoin appelle vraiment une interface. On ouvre un dépôt Git avant d'avoir dit qui déclenche les actions du système : un humain, un autre logiciel, ou l'horloge.

Le palier précédent a servi à récolter la matière : les exigences, puis les qualités de service qu'elles imposent. Ce billet ouvre le palier 2 avec la décision qui vient juste après, et avant la technologie : la forme de l'application.

Le type d'application n'est pas un détail d'implémentation, c'est une décision d'architecture à part entière. Changer de bibliothèque coûte des jours. Changer de forme coûte une réécriture.

Vue d'ensemble : six formes et trois questions

Avant de dessiner quoi que ce soit, le maître d'œuvre pose trois questions bêtes : qui entre dans le bâtiment, combien de temps il y reste, et combien ils sont à la fois. Un hangar où trois caristes circulent huit heures par jour et un hall de gare qui absorbe quinze mille personnes par heure ne sont pas la même chose, même à surface égale.

Les trois questions équivalentes, côté logiciel, tiennent en une ligne chacune.

1. Qui déclenche l'action ? Un humain devant un écran, un autre logiciel, ou le temps qui passe.
2. Combien de temps dure une action ? Une fraction de seconde, une session de travail, ou rien du tout parce qu'elle ne s'arrête jamais.
3. Où se trouve l'utilisateur, et de quoi a-t-il besoin autour de lui ? Un réseau fiable, du matériel local, un capteur, rien.

Les réponses désignent presque toujours l'une des six formes suivantes.

Ces six formes ne sont pas un catalogue de technologies. Ce sont six profils d'usage. On choisit d'abord un profil, la technologie vient ensuite.

Les six formes, une par une

Le programme d'un bâtiment décide de sa forme, et la forme décide de ses contraintes. Un entrepôt veut du sol libre et des quais ; une tour de bureaux veut des noyaux de circulation et des faux planchers. Chaque forme d'application fonctionne pareil : elle arrive avec ses évidences et ses interdits.

L'application web

L'utilisateur ouvre une adresse dans un navigateur, et c'est tout. Rien à installer, rien à mettre à jour côté client, un seul déploiement pour tout le monde. C'est la forme par défaut de la plupart des systèmes d'information depuis quinze ans, et pour de bonnes raisons.

Ses points forts tiennent ensemble : portée immédiate (n'importe qui avec une URL), correctif poussé en production sans que personne ne clique sur « mettre à jour », indépendance vis-à-vis du système d'exploitation du poste.

Le prix est tout aussi net. Elle exige un réseau disponible et une latence acceptable. Elle n'accède au matériel du poste que par ce que le navigateur veut bien exposer. Et son échelle est imprévisible par nature : une application web publique peut passer de deux cents à deux cent mille utilisateurs sans prévenir, ce qui remonte directement dans les exigences de charge.

Elle convient quand l'utilisateur est humain, sédentaire pendant sa session, et qu'aucune contrainte matérielle ne l'attache au poste : portail client, back office, outil métier interne, produit en libre service.

La Web API

Une Web API n'a pas d'interface. Personne ne la regarde. Ses clients sont d'autres logiciels : une application mobile, une application web, un partenaire, un autre service interne.

C'est la forme la plus mal expliquée des six, alors posons-la proprement. Le style REST, formalisé par Roy Fielding dans sa thèse de 2000, repose sur une idée simple : l'URL identifie une ressource, le verbe HTTP dit ce qu'on veut en faire, les paramètres précisent, et la réponse contient des données (typiquement du JSON), pas une page à afficher.

Concrètement, un appel ressemble à ceci.

GET /api/v1/capteurs/8f3a?depuis=2026-08-01 HTTP/1.1
Host: api.exemple.internal
Accept: application/json

Et la réponse ne contient que de la donnée, à charge du client de la mettre en forme.

{
  "id": "8f3a",
  "libelle": "Température quai 3",
  "unite": "degC",
  "derniereMesure": { "horodatage": "2026-08-23T18:04:11Z", "valeur": 21.4 }
}

Deux conséquences pratiques. D'abord, comme aucun humain ne lit les erreurs, les codes de retour HTTP sont l'interface : un 500 générique renvoyé pour une donnée invalide rend l'API impossible à intégrer. Ensuite, une API publiée est un contrat : dès qu'un client extérieur en dépend, la casser casse le code des autres. D'où le numéro de version dans la route, et une description formelle du contrat, par exemple au format OpenAPI.

L'application mobile

Le mobile n'est pas « le web en plus petit ». Son profil d'usage est radicalement différent : des sessions de quelques dizaines de secondes, répétées vingt fois par jour, souvent debout, souvent sur un réseau médiocre.

Ce qu'elle offre en propre : l'accès au matériel (GPS, appareil photo, lecteur de code, biométrie), les notifications qui rappellent l'utilisateur, et un fonctionnement hors ligne crédible quand elle est conçue pour.

Ce qu'elle impose est plus rarement anticipé. La distribution passe par des magasins d'applications, avec leurs délais de validation et leurs règles. Surtout, le parc installé n'est jamais homogène : une partie de tes utilisateurs restera des mois sur une vieille version. Ta Web API devra donc continuer à servir cette vieille version, ce qui n'est pas un détail de planning mais une contrainte d'architecture.

Le choix natif, hybride ou multiplateforme relève de la stack, traitée dans le billet suivant. Ici, la seule question est : le besoin justifie-t-il une application installée sur le téléphone, ou un site correctement adapté au mobile suffit-il ?

L'application console

Pas d'interface graphique, ou presque. On la lance avec des paramètres, elle travaille, elle rend un code de retour. Un planificateur peut la déclencher sans humain dans la boucle.

# Une console : des paramètres en entrée, un code de retour en sortie
./import-factures --source /flux/2026-08 --lot 500 --dry-run
echo $?   # 0 = succès, toute autre valeur remonte au superviseur

C'est la forme la moins chère à produire, puisque le poste de dépense principal des autres formes (l'interface) disparaît. Elle excelle sur les traitements par lot, les migrations de données, les outils d'administration et l'outillage interne des équipes.

Deux qualités la rendent utilisable en production : des paramètres explicites plutôt que des chemins codés en dur, et la capacité à être relancée sans dégât après un échec au milieu du traitement.

Quand un utilisateur demande « un écran avec un bouton qui lance le traitement de nuit », la bonne réponse est souvent une console plus une tâche planifiée.

Le service

Le service partage avec la console l'absence d'interface, mais il s'en distingue sur un point décisif : sa durée de vie. La console est lancée, fait son travail, se termine. Le service démarre avec la machine et n'est pas censé s'arrêter.

Il attend quelque chose : des messages dans une file, des connexions sur un port, des fichiers qui apparaissent, une échéance. Il est le bon choix pour tout traitement continu, en particulier tout ce qui doit absorber un flux sans faire attendre un utilisateur.

Parce que personne ne le regarde, un service mal conçu peut être tombé depuis trois jours sans que quiconque le sache. Sa forme impose donc, dès la conception, une politique de redémarrage, un point de contrôle de santé et une journalisation exploitable. La supervision centralisée qui va avec fait l'objet d'un billet dédié plus loin dans la série.

L'application desktop

Installée sur le poste, elle voit le matériel, le système de fichiers et le processeur local sans intermédiaire. Elle fonctionne sans réseau et garde les données sur la machine, ce qui est parfois une exigence de sécurité plutôt qu'un confort.

Son domaine est resté solide là où il compte : calcul lourd et local (conception assistée, montage, simulation), pilotage d'équipements, postes industriels ou scientifiques, environnements sans connexion fiable.

Sa faiblesse est le déploiement. Chaque mise à jour doit atteindre chaque poste, et un parc finit toujours par faire cohabiter trois versions différentes du même logiciel. C'est le coût d'exploitation qui disqualifie le desktop dans la majorité des cas où le web ferait l'affaire.

Chaque forme est excellente dans son couloir et mauvaise ailleurs. L'erreur n'est jamais « cette forme est dépassée », c'est « cette forme ne correspond pas à ce que les gens font vraiment avec le système ».

Le tableau qui tranche

Sur Le Chantier, changer de type d'ouvrage à mi-parcours n'est pas un avenant, c'est un nouveau permis de construire. Autant trancher avant de couler.

Voici les six formes lues sur les critères qui décident réellement.

L'autre façon de s'en servir est de lire les symptômes à l'envers. Quand une équipe souffre sans comprendre pourquoi, la cause est souvent une forme mal choisie au départ.

L'arbre ci-dessous condense les trois questions de départ.

Un arbre de décision ne remplace pas le jugement, il empêche de sauter la question. Le vrai gain est de rendre le choix explicite, donc discutable, donc documentable.

Les combinaisons : presque aucun système n'a une seule forme

Un chantier livre rarement un seul ouvrage. Un immeuble de bureaux arrive avec son parking enterré, son local technique et son quai de livraison, chacun avec ses règles propres, tous raccordés au même ensemble.

Les systèmes réels fonctionnent pareil. La combinaison la plus courante est application web plus service, à laquelle s'ajoute presque toujours une Web API dès qu'un second client apparaît.

Le scénario type : un client consulte ses commandes dans le navigateur, une application mobile fait la même chose en déplacement, un partenaire interroge le système par API, et toute la facturation de nuit tourne dans un service que personne ne regarde jamais.

Ce découpage se décide tôt, et pas pour des raisons esthétiques.

D'abord parce que la logique métier doit vivre à un seul endroit. Si l'application web calcule les remises dans son code et que le mobile refait le même calcul de son côté, tu as deux vérités, donc bientôt deux résultats différents pour le même client.

Ensuite parce que l'API devient une frontière publique. À partir du moment où un tiers l'appelle, toute évolution se négocie et se versionne. Extraire une API sous une application web existante, deux ans plus tard, revient à démonter la logique métier collée à la couche d'interface : c'est une réécriture qui ne dit pas son nom.

Enfin parce que chaque morceau hérite d'un profil non fonctionnel distinct. L'API encaisse le cumul de tous les clients ; le service se dimensionne sur le flux entrant ; l'application web vit ou meurt sur la latence perçue. Un dimensionnement unique pour l'ensemble se paie soit en argent, soit en incidents.

Le bon réflexe : nommer les formes du système avant d'ouvrir le premier dépôt de code. Le découpage en formes précède le découpage en composants.

Scénario B : Facebook et le pari HTML5, 2012

Le cas le plus documenté d'une forme mal choisie ne vient pas d'une petite équipe mal outillée, mais de l'une des entreprises les plus riches du secteur.

Avant 2012, l'application mobile de Facebook reposait largement sur du HTML5 encapsulé dans une enveloppe native. Le raisonnement était rationnel : une base de code, plusieurs plateformes, et des mises à jour livrées sans repasser par la validation des magasins d'applications.

Le 11 septembre 2012, sur la scène de TechCrunch Disrupt à San Francisco, Mark Zuckerberg a déclaré publiquement que le fait d'avoir trop misé sur HTML5 plutôt que sur le natif avait été la plus grosse erreur de son entreprise. La déclaration est restée célèbre parce qu'elle est rare : une entreprise qui qualifie elle-même sa décision d'architecture d'erreur stratégique.

La réécriture, elle, avait commencé avant la déclaration. Dès août 2012, Facebook publiait une application iOS reconstruite en natif, présentée par l'entreprise comme deux fois plus rapide que la précédente. L'application Android native a suivi en décembre. Les équipes ont documenté cette refonte sur leur blog d'ingénierie, notamment dans le billet « Under the hood: Rebuilding Facebook for iOS ».

Ce qui rend le cas instructif pour un architecte, ce n'est pas « HTML5 est mauvais ». C'est l'écart entre la forme choisie et le profil d'usage réel : des sessions de quelques secondes, répétées des dizaines de fois par jour, avec un défilement continu et des gestes attendus au doigt près. Sur ce profil d'usage, la fluidité est une fonction à part entière du produit.

Deux nuances pour rester juste. D'une part, le pari initial n'était pas absurde au regard du coût de maintenir deux applications distinctes. D'autre part, la même entreprise a publié React Native en 2015, ce qui montre que la question n'a jamais été tranchée une fois pour toutes par un camp contre l'autre.

Corriger une erreur de forme, ce n'est pas remplacer une bibliothèque : c'est réécrire un client entier. Facebook en a réécrit deux la même année.

Points clés

• Le type d'application est une décision d'architecture qui précède le choix des technologies. Elle découle du programme et des exigences, pas des préférences de l'équipe.
• Trois questions suffisent à la cadrer : qui déclenche l'action, combien de temps elle dure, de quoi l'utilisateur a besoin autour de lui.
• Une Web API n'a pas d'interface et n'a que des logiciels pour clients : URL de ressource, verbe HTTP, données en retour, codes d'erreur explicites, contrat versionné.
• Console et service se ressemblent mais s'opposent sur la durée de vie : la console se termine, le service ne s'arrête pas et doit donc être supervisé par conception.
• Un système réel combine plusieurs formes, et ce découpage se décide tôt : la logique métier doit vivre à un seul endroit, et chaque forme a son propre profil de charge.

Dans la série

Palier 2 : Dresser les plans. Domaine : Applications.

• Précédent : Les *-ilities : traduire les exigences en capacités techniques
• Suivant : Choisir sa stack technique, et les contraintes qui décident à ta place
• Vue d'ensemble : Architecture logicielle : par où commencer

Pour aller plus loin

• Choisir sa stack technique, et les contraintes qui décident à ta place, le billet suivant : une fois la forme choisie, les technologies qui la servent.
• Architecture des composants : couches, interfaces, injection, SOLID, pour descendre à l'intérieur de chacune de ces formes.
• Roy T. Fielding, « Architectural Styles and the Design of Network-based Software Architectures », chapitre 5 sur REST
• Spécification OpenAPI, pour décrire formellement le contrat d'une Web API.
• Progressive Web Apps sur MDN, la zone grise entre application web et application mobile.
• Blog d'ingénierie de Meta, où la refonte native des applications de 2012 a été documentée.