Si vous travaillez dans le numérique, vous avez forcément entendu une de ces phrases. Peut-être en hochant la tête, avec une idée assez floue de ce qu’il y avait derrière. Et c’est normal : c’est un de ces mots que tout le monde utilise et que personne ne prend le temps d’expliquer.

Je l’ai effleuré dans mon article sur les clés d’API, le temps de trois paragraphes. Mais je me suis dit que je n’expliquais pas assez. Parce que les API ne servent pas qu’aux agents IA : elles sont derrière à peu près toutes les applications que vous utilisez.

De mon côté, je baigne dedans depuis longtemps. J’en ai consommé dans les applications mobiles que j’ai développées, j’en ai conçu, et j’en ai souvent discuté avec des PO. Alors essayons de rendre ça simple.

Pour ça, je vous emmène à l’hôtel. Oui, encore. On y était déjà pour la clé d’API, autant y rester :)

Le room service

Vous êtes dans votre chambre, il est tard, vous avez faim. Vous n’allez pas descendre en cuisine, ouvrir le frigo et vous faire un gratin au milieu des cuisiniers. Ce n’est pas votre cuisine, vous ne savez pas où sont rangées les choses, et puis, vous n’avez tout simplement pas le droit d’y être.

À la place, il y a la carte du room service posée sur la table de votre chambre. Vous la lisez, vous choisissez ce que vous voulez, puis vous appelez pour commander ce délicieux gratin de ravioles (car vous avez très envie de cette spécialité de la Drôme) en donnant votre numéro de chambre. Un peu plus tard, on frappe : votre plateau est là.

Vous n’avez aucune idée de ce qui s’est passé en cuisine. Combien de cuisiniers, quel four, d’où vient la crème. Et vous n’avez pas besoin de le savoir. Vous avez fait une demande prévue par le menu, et vous avez reçu ce qui était annoncé.

Une API, c’est ce room service. Mais entre deux logiciels.

Une API, avec des mots simples

API veut dire Application Programming Interface, interface de programmation en français. Le mot important, c’est interface : un point de contact entre deux choses, avec des règles pour la manière de se parler.

Quand vous utilisez une application, vous passez par son interface graphique : des écrans, des boutons, des menus. C’est fait pour des humains. Un logiciel, lui, n’a ni yeux ni doigts. Quand il veut quelque chose d’un autre logiciel, il passe par une autre porte : l’API. C’est une liste de demandes que le service accepte de recevoir, avec la manière de les formuler et ce qu’il répondra.

Prenez l’application météo de votre téléphone. Elle n’a pas de stations météo sur les toits. Elle demande les prévisions à un service spécialisé, via son API, et se contente de les afficher joliment. Le service météo, c’est la cuisine. L’application, c’est vous dans la chambre.

Une demande, une réponse

Concrètement, ça fonctionne par échanges. Un logiciel envoie une demande (on dit une requête), l’autre renvoie une réponse.

La requête de l’application météo ressemble, en gros, à « donne-moi la météo de Paris pour demain ». Et la réponse pourrait ressembler à ça :

{
  "ville": "Paris",
  "date": "2026-11-08",
  "temperature": 9,
  "ciel": "nuageux",
  "pluie": "20 %"
}

Pas de jolie icône de nuage, pas de mise en page. Juste les informations, rangées dans un format que n’importe quel programme sait lire (celui-là s’appelle JSON, et vous en croiserez très souvent).

C’est un point que je trouve important quand on travaille sur un produit : l’API donne les informations, pas l’affichage. C’est l’application qui décide quoi en faire : un gros chiffre sur l’écran d’accueil, un widget, une notification « prenez un parapluie ». La même réponse peut servir un site web, une application mobile, une montre connectée ou l’application d’un partenaire.

La carte, c’est la documentation

Revenons au room service. Ce qui rend tout ça possible, c’est la carte. Elle dit ce qu’on peut commander, comment le demander, et ce qu’on va recevoir.

Une API a la même chose : sa documentation. Elle est écrite par l’équipe qui fabrique l’API à destination des développeurs qui vont s’en servir. « Pour obtenir la météo, envoyez telle demande à telle adresse, en précisant la ville et la date. Vous recevrez la température, le ciel et le risque de pluie. »

Et comme au room service, ce qui n’est pas sur la carte ne se commande pas. Vous pouvez réclamer une pizza tant que vous voulez, si elle n’y est pas, la cuisine ne la fera pas. Une API ne fait que ce qui a été prévu. Si elle ne donne pas la vitesse du vent, l’application ne pourra pas l’afficher, même si le service météo la connaît parfaitement.

C’est souvent ce qui se cache derrière « ce n’est pas possible, ce n’est pas dans l’API ». Le service sait peut-être le faire, mais il ne le propose simplement pas à l’extérieur (ou pas encore).

Il y en a partout

Une fois qu’on a l’image en tête, on en voit partout.

• Vous payez sur un site marchand : le site transmet le paiement à l’API d’un service comme Stripe ou PayPal, qui répond « accepté » ou « refusé ».
• Votre fil d’actualités sur votre réseau social préféré, il vient d’une API. Tout l’algorithme est sur le serveur.
• Vos outils se parlent dans n8n ou Zapier : chaque étape, c’est un appel à l’API d’un service.
• Et les IA aussi : Claude et ChatGPT ont leur API, qui permet à d’autres applications d’utiliser leurs modèles (c’est d’ailleurs comme ça qu’on peut ajouter de l’IA dans une application mobile).

Et puis il y a toutes celles qu’on ne voit jamais. Par exemple un outil de tracking pour permettre d’analyser le trafic d’un site. Ou même les API que le serveur lui-même consomme pour vous fournir les bonnes informations - eh oui, il y a parfois des intermédiaires.

Publique, partenaire ou interne

Toutes les API ne sont pas ouvertes à tout le monde.

Le room service est réservé aux clients de l’hôtel. Mais la même cuisine prépare aussi les plats du restaurant, du bar, et peut-être les repas du personnel. Une cuisine, plusieurs guichets, chacun avec sa carte.

Pour les API, c’est pareil :

• une API publique est ouverte à qui veut (souvent avec une inscription et une clé) : la météo, Notion, Slack ;
• une API partenaire n’est accessible qu’à quelques entreprises, avec un contrat ;
• une API interne ne sert qu’à l’entreprise elle-même, entre ses propres logiciels et ses équipes.

Dans les applications mobiles que j’ai développées, il y avait l’application d’un côté, le serveur (le back-end) de l’autre, et une API interne au milieu pour qu’ils se parlent. Parfois, des API de services tiers venaient s’y ajouter. On peut même aller jusqu’à fabriquer une API sur mesure pour une seule application, j’en parlais à propos du Backend for Frontend.

Ce que ça change quand on travaille sur un produit

Si vous êtes PO, designer, chef de projet, ou simplement curieux de ce que racontent les développeurs, voilà ce que je trouve utile d’avoir en tête.

Une API, c’est un contrat. Une fois la carte écrite et acceptée, la cuisine et les clients peuvent avancer chacun de leur côté. L’équipe mobile n’a pas besoin d’attendre que le serveur soit terminé : elle connaît la forme des réponses et peut travailler avec de fausses données en attendant (on appelle ça des mocks). C’est souvent ce qu’il y a derrière « on attend l’API / on attend le back-end » : soit le plat n’est pas encore cuisiné, soit, plus embêtant, la carte n’est pas encore écrite.

On ne change pas la carte du jour au lendemain. Si vous retirez le gratin, les habitués qui le commandaient chaque soir vont être déçus. Pour une API, c’est pire : les logiciels qui l’utilisent cassent. C’est pour ça qu’on parle de versions. On garde l’ancienne carte un moment, on publie la nouvelle à côté, et on prévient avant de retirer l’ancienne. Une modification qui paraît anodine (renommer un champ, changer le format d’une date) peut demander beaucoup de coordination quand d’autres en dépendent. Faites discuter vos équipes !

La cuisine a ses limites. Elle ne peut pas préparer mille plateaux à la minute. Beaucoup d’API limitent le nombre de demandes autorisées (on parle de rate limit), et certaines sont payantes à l’usage. Bon à savoir avant d’imaginer une fonctionnalité qui interroge un service toutes les secondes.

Dépendre d’une API, c’est dépendre de quelqu’un. Si la cuisine ferme, plus de room service. Si un service tiers tombe en panne, change ses conditions ou ferme son API, la fonctionnalité qui en dépend s’arrête aussi. Ça ne veut pas dire qu’il faut s’en priver, mais ça vaut le coup de se demander ce que fait le produit quand la réponse n’arrive pas.

Il faut dire qui commande. Au room service, on donne son numéro de chambre, pour savoir où livrer et sur quelle note mettre le plateau. La plupart des API demandent la même chose. C’est le rôle de la clé d’API, le badge d’hôtel dont je parlais dans l’article précédent.

Et les agents IA, dans tout ça ?

Un agent IA est un logiciel. Quand vous lui demandez de lire votre agenda ou de créer une page Notion, il ne va pas cliquer dans l’interface comme vous le feriez (enfin, la plupart du temps). Il passe par l’API du service.

Souvent pas directement : un connecteur ou un MCP fait l’intermédiaire. Mais en bout de chaîne, ce sont souvent des appels à une API. C’est pour ça qu’un service sans API est difficile à brancher à un agent.

J’en parle plus en détail dans la série sur la connexion d’un agent à vos outils.

Avec quoi on repart ?

Une API, au fond, c’est une forme de discussion et un contrat entre logiciels. On ne débarque pas dans la cuisine des autres : on lit la carte, on commande ce qui est prévu, on donne son numéro de chambre, et on reçoit son plateau. On fait une demande, on obtient une réponse.

Il existe aussi un autre cas intéressant : quand c’est l’hôtel qui doit vous prévenir, sans que vous ayez rien demandé. C’est le principe du webhook, et il aura son article dans la série.

Connecter un agent IA à d’autres services :

• Comment connecter son agent IA à ses outils (Gmail, Notion, Google Agenda…) ?
• C’est quoi un connecteur IA ? Relier Claude ou ChatGPT à vos outils en quelques clics
• C’est quoi un MCP ? Le port USB-C qui branche votre agent IA à vos outils
• C’est quoi une clé d’API ? Le badge d’hôtel qui ouvre vos outils à votre agent IA
• C’est quoi un CLI ?
• C’est quoi un webhook ?

Hors-série complémentaire :

• C’est quoi une API (Application Programming Interface) ?

Une clé d’API, c’est une longue suite de lettres et de chiffres qui pourrait ressembler à sk-4f9a2c.... Et partout où on en parle, le même avertissement revient : ne la partagez avec personne.

Alors c’est quoi au juste ? Un mot de passe ? Un code d’accès ? Un peu des deux. Pour l’expliquer, je vous propose une image : le badge d’une chambre d’hôtel. Gardez-la en tête, on va s’en servir tout le long.

Pourquoi connecter son agent, déjà ?

Petit rappel, si vous arrivez directement ici.

Un agent IA repose sur un modèle qui a appris énormément de choses sur le monde. Mais il ne sait rien de vous. Il n’a jamais vu vos mails, votre agenda, vos notes ou vos projets. Ses réponses sont justes en général, rarement justes pour vous.

En le branchant à vos outils, il travaille avec vos vraies données, à jour. Et il peut agir à votre place : ranger, créer, préparer, envoyer.

C’est le sujet de l’article qui ouvre cette série, si vous voulez creuser.

D’abord, c’est quoi une API ?

Quand vous utilisez Notion, vous passez par son interface : des pages, des boutons, des menus. C’est pensé pour des humains, avec des yeux et une interface pour interagir (souris, trackpad, écran tactile).

Un programme lui n’a pas besoin de toute cette mise en page et navigation. Il se sert d’une autre entrée : l’API, pour Application Programming Interface (interface de programmation, en français). C’est une liste de demandes que le service accepte, formulées d’une manière bien précise.

Ce sont les développeurs du service qui vont créer et gérer l’API pour que d’autres développeurs (et donc programmes) puissent interragir avec le service en question d’une manière cadrée et définie à l’avance. Une documentation n’est jamais bien loin - « Pour créer une tâche, il faut appeler cette url et il faudra indiquer ces informations dans ces champs là ».

Presque tous les services en ont une : Notion, Slack, et bien sûr les IA elles-mêmes. Petite note, les MCP et connecteurs dont je parlais dans les articles précédents ne font parfois rien d’autre que parler à cette API à votre place.

J’ai pris le temps de détailler tout ça, avec une histoire de room service, dans un article dédié aux API.

Et la clé, alors ?

Une API ne répond pas à n’importe qui. Avant de donner vos pages Notion, elle veut savoir deux choses : qui demande ? A-t-il le droit ?

La clé répond aux deux d’un coup. Le programme la joint à chacune de ses demandes, et l’API sait à qui elle a affaire.

C’est là que l’hôtel entre en scène. À votre arrivée, la réception vérifie votre identité une fois, puis vous tend un badge. Ensuite, plus besoin de sortir votre passeport devant chaque porte : vous passez le badge, et ça s’ouvre. La porte ne sait pas vraiment qui vous êtes. Elle sait que ce badge est lié à la chambre 117 et qu’il a le droit d’entrer.

La clé d’API fonctionne pareil. Vous vous connectez une fois à votre compte, vous créez une clé, et vous la donnez à l’outil ou à l’agent. Il ne connaîtra jamais votre mot de passe. Et le service considère chaque demande faite avec cette clé comme venant de vous.

Pour moi, ça n’a rien de nouveau. En tant que développeur, je manipule des clés d’API depuis bien avant les LLM et les agents. Dès qu’on veut qu’un programme utilise un service, c’est le geste de base : on fait ses appels avec une clé pour s’authentifier. Dans les applications mobiles que j’ai créées pour mes clients, il y en avait parfois pour des services tiers.

Ce qui change aujourd’hui, c’est que ce ne sont plus seulement les développeurs qui en voient passer. Avec les agents, tout le monde finit par tomber dessus.

Ce qui est bien avec une clé d’API

Ça marche presque partout. Les clés d’API existent depuis longtemps, et quasiment tous les services en proposent. Même ceux qui n’ont ni connecteur ni MCP. Et ça ne dépend pas de l’IA que vous utilisez : la même clé fonctionne avec Claude, ChatGPT, n8n ou un petit script.

Elle agit en votre nom. Au bar de l’hôtel, on vous propose de mettre la consommation sur la note de la chambre. Le badge est lié à vous. Une clé aussi : ce que l’agent fait avec, le service le compte comme fait par vous, sur votre compte, avec vos données.

On peut en avoir plusieurs. La réception fait un badge par personne de la chambre. De la même façon, on peut créer une clé par usage : une pour l’agent, une pour n8n, une pour telle application. Chacune avec son nom. On sait qui fait quoi, et on peut en couper une sans toucher aux autres.

On choisit les portes. Votre badge ouvre votre chambre, la salle de sport et la piscine. Pas les autres chambres, ni la cuisine. Beaucoup de services permettent la même chose : une clé en lecture seule, une clé qui ne voit qu’un seul projet, une clé qui peut créer mais pas supprimer. On dit qu’on « scope » la clé, qu’on limite sa portée.

J’aime bien quand un service le permet. Je peux restreindre la clé à ce dont l’outil a vraiment besoin. C’est le principe que je défends depuis le début de cette série : le meilleur moyen d’empêcher un agent de faire une bêtise, ce n’est pas de le lui interdire dans un prompt, c’est de ne pas lui en donner la capacité.

On ne donne pas son mot de passe. L’agent n’a jamais vos identifiants. Il ne peut pas essayer de se connecter avec sur un autre service. Il ne va pas non plus le divulguer, volontairement ou non. Attention par contre, la clé, elle, pourrait fuiter selon la façon dont on la donne à l’agent.

On la retire en un clic. Badge perdu ? La réception le désactive et vous en refait un. Votre séjour continue. Une clé, c’est pareil : vous la supprimez, votre compte reste intact, votre mot de passe ne change pas, vos autres clés continuent de fonctionner. Si quelqu’un a trouve une clé qui a fuité, il ne peut rien en faire, elle a été désactivé.

Où on la trouve, où on la met

Pour la trouver, direction les paramètres du service. La rubrique s’appelle souvent « API », « Développeurs », « Intégrations » ou « Clés ». On clique sur « Créer une clé », on lui donne un nom, parfois on choisit ses droits, et la clé apparaît.

Souvent, elle n’est affichée qu’une seule fois. Copiez-la tout de suite. Si vous la perdez, pas de panique : on la supprime et on en refait une. Comme le badge.

Pour la mettre, ça dépend de l’outil. Certains ont un champ prévu pour (n8n, la configuration d’un MCP, une application). Les agents qui tournent sur votre machine la lisent souvent dans un fichier de réglages, rangé à part.

Un réflexe à prendre, par contre : évitez de coller la clé directement dans la conversation. Ce que vous écrivez dans le chat est conservé dans l’historique, chez le fournisseur de l’IA, et peut se retrouver dans d’autres fichiers. Une clé, c’est mieux rangée à un seul endroit, prévu pour ça.

Clé d’API ou connexion avec son compte ?

Dans l’article sur les connecteurs, je disais que l’un de leurs avantages, c’est de ne pas avoir de clé à manipuler. On clique sur « Se connecter avec Google », on accepte les accès, et c’est fini.

En coulisse, il y a quand même une sorte de clé. Sauf que c’est le service qui la fabrique, la range et la renouvelle tout seul. Vous n’y touchez jamais. (Ça s’appelle OAuth, et vous n’avez pas besoin de retenir le nom.)

Alors, laquelle choisir ? J’ai envie dire, peu importe, ça aura souvent la même finalité. Regardez peut-être s’il y a une différence dans les droits d’accès accordés (le scope).

Les risques

C’est un secret utile. Un badge trouvé dans le couloir ouvre votre chambre. La porte ne vérifie pas que c’est bien vous qui le tenez. Une clé d’API, c’est pareil : celui qui la possède agit en votre nom. Il peut lire vos données, les modifier ou les supprimer selon les droits de la clé. Et si le service est payant, il dépense votre argent.

Elle fuit facilement. Une capture d’écran partagée un peu vite, un message à un collègue, un document collaboratif, un projet publié en ligne… Une clé, c’est du texte, et le texte se copie partout. Certains services repèrent les clés publiées par erreur et les désactivent d’office mais ne comptez pas trop dessus.

Les agents aussi peuvent la lire. Un agent qui a accès à vos fichiers a accès à ceux où dorment vos clés. Un MCP ou un skill malveillant peut aller les chercher. C’est un des risques que je décrivais à propos des skills : vérifiez ce que vous installez.

Quelques réflexes simples, donc :

• une clé par usage, avec un nom clair ;
• les droits minimum, quand le service permet de les choisir ;
• un plafond de dépense, quand le service est payant ;
• jamais dans le chat, sur une capture ou dans un document partagé ;
• au moindre doute, on la supprime et on en refait une. C’est l’affaire d’une minute.

Un badge, pas une baguette magique

Une clé d’API n’a rien de mystérieux, ni de réservé aux développeurs. C’est un badge. Il ouvre les bonnes portes à votre agent, en votre nom, sans jamais lui confier votre mot de passe.

Et comme un badge d’hôtel, on le garde pour soi, on ne lui donne pas plus de portes que nécessaire, et on le fait désactiver au moindre doute.

Prochaine étape de la série : le CLI. Ces outils qu’on pilote en tapant des commandes, que les agents adorent, et qui réclament souvent… une clé d’API.

Connecter un agent IA à d’autres services :

• Comment connecter son agent IA à ses outils (Gmail, Notion, Google Agenda…) ?
• C’est quoi un connecteur IA ? Relier Claude ou ChatGPT à vos outils en quelques clics
• C’est quoi un MCP ? Le port USB-C qui branche votre agent IA à vos outils
• C’est quoi une clé d’API ? Le badge d’hôtel qui ouvre vos outils à votre agent IA
• C’est quoi un CLI ?
• C’est quoi un webhook ?

Hors-série complémentaire :

• C’est quoi une API (Application Programming Interface) ?

On a envie d’associer les deux, d’avoir notre IA de poche. En tant que créateur d’applications mobiles (Product Owner, Développeur, Designer), on peut y participer !

J’en profite pour expliciter les différentes interactions qu’il peut y avoir avec l’IA sur un smartphone :

• Un utilisateur peut jouer avec l’IA du système qui est intégré dans divers composants pour par exemple reformuler une phrase, générer une image, faire une action, etc. Le développeur n’a pas la main dessus, c’est le système qui gère.
• Le développeur peut apprendre à l’IA du système comment interagir avec son application, en exposant certaines données et intentions. L’utilisateur pourra par exemple lancer une action réalisée par l’application via Siri.
• Le développeur peut créer des fonctionnalités boostées à l’IA au sein de son application. L’utilisateur pourra s’en servir depuis l’application.

Aujourd’hui, on va se concentrer sur le dernier cas : créer des fonctionnalités augmentées par l’IA. On va se donner un aperçu de ce que l’on pourrait faire dans nos applications et des options pour y arriver.

Quelques exemples d’usages

Ce que l’on voit le plus souvent, ce sont des fonctionnalités qui manipulent un contenu textuel déjà présent. On propose de résumer l’article actuellement affiché dans une application de news, par exemple. On pourrait aussi sélectionner un paragraphe et demander plus d’explications. Ou même traduire. On peut également proposer à l’utilisateur d’améliorer le contenu qu’il a créé - il pourrait reformuler, corriger, compléter.

Générer du contenu grâce aux données personnalisées est un autre usage intéressant. Une application de liste de courses pourrait par exemple proposer des idées de recette en fonction des aliments ajoutés par l’utilisateur. Peut-être même que des recommandations pourraient apparaître autour de la nutrition.

Et pourquoi pas un champ de texte voire un chat pour trouver et utiliser des fonctionnalités existantes dans l’application ? Sur une application complexe avec beaucoup de pages et de profondeur, ce pourrait être pratique. L’utilisateur pourrait demander de “réserver un aller-retour à Valence pour demain” ou “envoyer 100€ à ma mère” avec ses propres mots.

De nombreuses possibilités existent aussi du côté des jeux. En faisant varier des dialogues, ou en les créant pleinement. En générant des niveaux, des parties, des quiz. Peut-être même que l’utilisateur pourrait indiquer un thème, non prévu initialement, et le modèle d’IA ferait le reste. On commence tout juste à gratter la surface, à imaginer de nouveaux usages.

État des lieux

Les innovations et les possibilités qui tournent autour de l’IA vont vite (sauf chez Apple, qui a à la fois du retard et un cycle de release long - petite balle perdue gratuite :)). Où en est-on aujourd’hui ?

Commençons du côté de la pomme. Le flagship actuel est l’iPhone 16 Pro. iOS est en version 18.2.1. Apple Intelligence est disponible à partir de iOS 18.1 sur l’ensemble des modèles d’iPhone 16, ainsi que le 15 Pro et le 15 Pro Max. En Europe, on doit cependant attendre le mois d’avril pour accéder au système Apple Intelligence.

Sur Android, la dernière version est actuellement la 15 (API 35). Gemini est l’actuel modèle d’IA de Google, et d’autres constructeurs comme Samsung ajoutent aussi leur propre couche d’intelligence (Galaxy IA). Certains smartphones récents ont le droit à Gemini nano pour une exécution locale : c’est à partir du Google Pixel 8 Pro et Samsung S24, et d’autres appareils s’ajoutent progressivement.

Les deux systèmes proposent bien aux utilisateurs des fonctionnalités augmentées par l’IA. Mais côté développement, on est très limité pour créer. iOS ne propose que les App Intents pour faire découvrir nos applications à Siri et Spotlight. Et sur Android, Gemini nano est au stade expérimental. Il y a très peu d’appareils compatibles et les possibilités sont limitées.

À côté de cela, on voit d’autres solutions légères qui émergent pour être exécutées sur un smartphone. On trouve par exemple les ensembles de modèles Gemma de Google, Phi de Microsoft ou encore Llama de Meta. Ces trois familles de modèles sont d’ailleurs open-source. Plus étonnant, on trouve également des outils comme PicoLLM qui permettent de compresser les modèles !

Évidemment, tout ce que je raconte au-dessus changera avec le temps. Il y aura de nouveaux appareils, des nouvelles versions d’OS, des LLMs, etc. Un prochain rendez-vous que l’on peut prévoir : mai et juin pour les keynotes d’Apple et de Google, puis quelques temps après la sortie des nouvelles majeures d’OS.

Comment avoir accès à un modèle ?

Actuellement, pour créer des fonctionnalités augmentées par l’IA dans une application mobile, il faut interagir avec un modèle. On va créer des prompts adaptés à nos cas d’utilisations puis interpréter la réponse. Une réponse que l’on aura forcée dans un standard (du JSON par exemple).

Pour que notre application communique avec un modèle, nous avons plusieurs options.

Via notre serveur et une API tierce

C’est actuellement un des choix les plus répandus et les plus efficaces. Les applications mobiles ont déjà l’habitude de discuter avec des serveurs - on aura simplement de nouvelles routes pour obtenir des inférences. Notre serveur fait la passerelle vers l’API d’OpenAI par exemple, et ce sont ces derniers qui hébergent le modèle.

Les intérêts sont multiples. On peut cibler tous les appareils (puissant ou entrée de gamme, récent ou vieux) et tous les systèmes (Android, iOS) peu importe la version (la toute dernière comme la plus vieille). Eh oui, il ne s’agit là que de requêtes HTTP et de stream de données.

On s’assure au passage d’avoir le même comportement entre les différents appareils et systèmes, puisque c’est le même modèle qui est utilisé en bout de chaîne. Les règles métiers et prompts sont aussi partagées. On pourra facilement et rapidement les modifier à distance sans mettre à jour les applications mobiles.

D’ailleurs, on peut aussi changer le modèle utilisé par un autre (une nouvelle version ou un concurrent) sans devoir redéployer notre application. Tout comme on pourrait utiliser plusieurs modèles en parallèle.

Le coût sera cependant élevé. La charge principale viendra de l’utilisation d’un service tiers comme OpenAI. Le coût augmentera selon deux vecteurs : le nombre d’utilisateurs et le nombre d’usages. En effet, les API tiers facturent au nombre de token généré pour l’utilisation de leurs LLMs.

C’est d’autant plus important que notre serveur agisse en tant qu’intermédiaire : une communication directe entre les applications et le service tiers impliquerait d’exposer en public nos clés d’APIs. Il serait alors très facile pour une personne d’utiliser nos clés, augmentant ainsi notre facture.

Quelques solutions : OpenAI, Anthropic, Gemini. On peut ajouter Firebase qui est une rare solution à proposer un accès direct (sans serveur) sécurisé à une LLM (Gemini en l’occurrence).

Via notre serveur qui héberge un modèle

Le second choix qui est également très répandu est celui d’héberger soi-même un modèle sur nos serveurs. On garde ainsi les avantages de passer par notre serveur (compatibilités avec tous les appareils, facilité de changement du modèle, utilisation de plusieurs modèles, …) tout en ayant plus de contrôle.

Un des aspects les plus intéressant concerne les données. En hébergeant un modèle open-source, on s’assure un meilleur contrôle sur nos données et la manière dont elles sont utilisées, et surtout par qui.

Le coût sera aussi maîtrisé différemment. Exit un prix au token via une API tierce, cette fois on paie l’hébergement du modèle.

Maintenant, comment choisir entre utiliser une API tierce et héberger un modèle ? Quelques insight possibles pour décider :

• passer par une API tierce pour prototyper rapidement, quand on est une petite entreprise, qu’il n’y a pas de données confidentielles.
• héberger un modèle quand on est une plus grande entreprise, quand on veut mieux contrôler l’usage des données.

Quelques solutions : Mistral qui est open-source et français, se balader sur le marketplace de Hugging Face.

En local avec les solutions natives

Il existe aujourd’hui des modèles plus légers qui peuvent fonctionner sur nos ordinateurs et nos téléphones, et certains appareils les intègrent par défaut. On peut donc les utiliser directement pour faire des inférences « on-device ».

Il y a plusieurs avantages à cette exécution locale. Premièrement, le coût. Il n’y en a tout simplement pas. Pas besoin de payer un service tiers ou d’héberger une solution existante, le modèle est déjà présent sur le téléphone. En fait, c’est l’utilisateur qui porte le coût : c’est la puissance de son smartphone, via sa puce et sa batterie, qui réalisera toutes les opérations. On pensera alors à ménager sa batterie.

Deuxièmement, la confidentialité. Le modèle étant sur l’appareil, les données sensibles n’ont pas besoin de transiter sur internet ou d’être lues par un serveur tiers. C’est une des promesses phares de ces modèles. On restera méfiant tout de même s’il faut utiliser des données très sensibles - l’inférence est peut-être locale, mais des logs et données pourraient très bien remonter à des serveurs.

La rapidité est un potentiel troisième avantage. L’inférence locale s’oppose à une inférence sur un serveur distant qui nécessite des aller-retour sur internet. La communication réseau prenant du temps, on tient là un gain intéressant. Je parlerais d’ailleurs plutôt de meilleure latence de réponse. D’une certaine manière, les serveurs d’OpenAI (par exemple) sont bien plus puissants que les puces de nos smartphones. Ce n’est pas l’inférence qui est plus rapide, mais plutôt le délai pour obtenir les réponses (grâce à des étapes en moins). À condition bien sûr d’avoir un smartphone haut de gamme.

Tient-on alors la solution parfaite ? Aujourd’hui en tout cas, on en est loin. On est très limité en termes de cibles compatibles. Il n’y a rien sur iOS, Apple ne permet pas de prompter avec son Apple Intelligence. C’est réalisable seulement sur Android, et même là, les smartphones disposant d’une solution intégrée (Gemini Nano) sont peu nombreux, récents, et chers. Le pourcentage d’utilisateurs que l’on pourrait atteindre est faible.

C’est également toujours marqué par Google comme expérimental, et selon les smartphones, le modèle n’est pas pleinement intégré par défaut, il faut effectuer quelques actions.

Un point d’attention qu’il faudra garder en tête le jour où les modèles embarqués seront plus répandus : leurs différences. Apple et Google proposeront chacun leurs solutions, et il sera difficile (impossible ?) de reproduire avec certitude les mêmes comportements.

scope.launch {
  // Single string input prompt
  val input = "I want you to act as an English proofreader. I will provide you
    texts, and I would like you to review them for any spelling, grammar, or
    punctuation errors. Once you have finished reviewing the text, provide me
    with any necessary corrections or suggestions for improving the text: These
    arent the droids your looking for."
  val response = generativeModel.generateContent(input)
  print(response.text)

  // Or multiple strings as input
  val response = generativeModel.generateContent(
  content {
    text("I want you to act as an English proofreader. I will provide you texts
      and I would like you to review them for any spelling, grammar, or
      punctuation errors.")
    text("Once you have finished reviewing the text, provide me with any
      necessary corrections or suggestions for improving the text:")
    text("These arent the droids your looking for.")
    }
  )
  print(response.text)
}

En local avec un modèle à intégrer

En attendant qu’une grande majorité des appareils Android et iOS embarquent au sein de leurs systèmes des modèles accessibles aux développeurs, une solution pour avoir une exécution locale serait d’intégrer soi-même un modèle existant dans l’application.

Ainsi, on peut théoriquement cibler bien plus d’appareils et de systèmes / versions ; tant que ceux-ci sont assez puissants. On garderait alors la plupart des avantages d’une inférence locale : la rapidité sur les bons appareils, la confidentialité, et le coût réduit.

Réduit, mais pas inexistant. Le modèle n’étant pas embarqué dans le système de l’appareil, il faut le rendre téléchargeable… et donc l’héberger. On aura un coût de stockage et de bande passante. La bonne nouvelle, c’est que le téléchargement ne doit se faire qu’une seule fois par l’utilisateur au moment où l’application en aura besoin. Chaque usage sera ensuite totalement local et n’aura pas d’impact sur les coûts.

Cette contrainte a un second désavantage : elle requiert un effort pour l’utilisateur. Il devra télécharger un modèle. Même si l’application fait tout le travail, l’utilisateur va devoir patienter - un modèle étant lourd. Il devra aussi réserver de la place sur son appareil pour stocker ce modèle. Modèle qui ne fonctionnera que sur cette application.

Imaginons que plusieurs applications optent pour cette solution, cela représenterait des gigaoctets de téléchargement et de stockage. Ce n’est pas viable.

Quelques solutions : Gemma de Google, Phi de Microsoft, Llama de Meta. PicoLLM pour la compression.

final gemma = FlutterGemmaPlugin.instance;

// Async response
String response = await gemma.getResponse(prompt: 'Tell me something interesting');
print(response);

// Stream response
gemma.getAsyncResponse(prompt: 'Tell me something interesting').listen((String? token) => print(token));

En bref

Les LLMs ne sont plus seulement utilisés à travers des applications de chat où l’utilisateur écrit des prompts. On est dans une phase d’exploration où beaucoup de possibilités restent à être imaginée et testée, mais des premiers usages existent déjà au sein d’applications mobiles.

Et cela va très vite. Les idées fusent, les PoC se multiplient, et les appareils avec des modèles on-device vont se répandre. Les fonctionnalités augmentées par l’IA pourraient devenir un incontournable. Il nous est déjà possible d’en créer, il ne tient qu’à nous d’explorer.

J’ai fait le test avec mon téléphone, j’ai eu du mal à trouver une application qui ne faisait aucune requête (en tout cas en apparence, je n’en suis même pas sûr à 100%). J’ai la calculatrice qui vit sa vie dans son coin.

Pourquoi je raconte ça ? Parce que ces applications font très probablement des requêtes vers un serveur qui leur appartient. En d’autres termes, l’équipe, le département, ou l’entreprise qui gère le développement de l’application est également responsable du serveur.

Dans l’épisode précédent, on a vu qu’une configuration à distance permettait de changer le comportement d’une application mobile. Et que la configuration à distance, ce pouvait être simplement un fichier JSON ou une API qui exposait quelques valeurs.

De là à faire le rapprochement entre les données envoyées par nos serveurs et la possibilité de changer le comportement d’une application mobile à distance, il n’y a vraiment qu’un petit pas. Alors faisons-le !

Vers une API spécialisée

En général, ce qu’on retrouve souvent, c’est un backend qui tends vers de l’envoi de données brutes aux fronts. Et qui s’approche plus ou moins du REST. Pour alimenter une page, le front mobile devra effectuer une ou plusieurs requêtes puis traiter les données, appliquer un peu de logique.

Imaginons une page agenda sur notre application. On a envie de mettre en valeur les événements qui ont lieu aujourd’hui, dans de jolis encarts avec un maximum d’informations, ainsi que les 3 prochains événements. Pour le reste, on les groupe par semaine glissante et juste le titre nous suffira.

Notre backend nous propose une route qui retourne 100 événements, à partir du début de la semaine. Côté front mobile, on va devoir trier par date, filtrer les événements passés, mettre de côté les événements du jour et également les 3 prochains pour la mise en valeur, puis ensuite faire des groupes par semaine glissante.

Beaucoup de logique métier qui se retrouve côté client (l’application). Si on décide de changer, disons par exemple la sélection des événements qui sont mis en valeur, il faut modifier l’application et donc redéployer, ce qui implique de traverser tout le process de soumission sur les stores que l’on aimerait éviter.

Sans parler des données qui transitent sur le réseau : on a besoin que du titre pour une grande partie des événements. On augmente au passage la charge serveur pour rien. Bonne nouvelle, on a dit qu’on est responsable du serveur - on peut décider d’y déporter certaines logiques.

Le backend pourrait :

• Trier dans l’ordre adapté,
• Ne renvoyer que les futurs événements.
• Porter la mise en valeur en envoyant deux listes distinctes, et indiquer juste le titre pour les événements lointains.
• Grouper par semaine glissante.
• Aller plus loin en portant la logique de présentation. “Afficher une carte avec un titre, une description, une date pour cet événement mis en valeur, afficher un simple titre pour cet événement, etc”. On commencerait alors à parler de Server-Driven UI.

En fonction de ce que l’on déporte sur le backend, on pourra modifier le comportement de l’application à distance en déployant une nouvelle version du backend plutôt que de l’application. Et c’est souvent bien plus rapide.

Notre API, qui était généraliste, devient spécialisée pour un front.

Le cas GraphQL

Un petit aparté sur GraphQL. Je le mettrais bien dans le panier API généraliste pour notre histoire. Oui, ça apporte une certaine flexibilité au front qui consomme l’API, il peut sélectionner ce qu’il veut, mais à la fin, c’est toujours le front qui construit les requêtes. On veut finalement filtrer les événements passés ? Eh bien il faut redéployer l’application.

Certes, c’est une modification très simple puisque c’est peut-être seulement un paramètre dans la requête GraphQL à ajouter ou modifier, mais cette modification est à faire côté client (notre application). Elle impliquera une soumission de la version sur les stores.

On n’est pas dans la spécialisation de notre API, elle ne porte pas de la logique supplémentaire dédiée au front.

Backend for Frontend

Avoir une API spécialisée, ça peut nous embêter dans certains cas. Si j’ai plusieurs fronts par exemple : un site web et une application mobile. Il y a parfois une logique différente entre les deux. Le web est une autre plateforme, l’interface est très différente. Pour l’agenda, je veux tout afficher sous la forme d’un calendrier mensuel.

On comprend donc l’intérêt d’avoir une API généraliste qui essaye de faire plaisir à tout le monde. Pour autant, on perçoit aussi les avantages d’avoir une API spécialisée. C’est là qu’intervient le principe de Backend for Frontend : on peut avoir les deux !

Un Backend For Frontend, souvent connu avec l’acronyme BFF, est une couche intermédiaire entre un backend et un frontend. Concrètement, c’est un backend supplémentaire qui va traiter des données spécifiquement pour un type de front (une application mobile par exemple).

Notre front mobile va effectuer toutes ses requêtes en passant par le Back for Front, et uniquement ce dernier. C’est le Back for Front qui appellera le backend pour obtenir les données nécessaires. Il pourra ensuite appliquer de la logique dédiée avant de renvoyer les données à l’application mobile. Le site web aurait de son côté son propre Back for Front.

Vu que le Back for Front devient le point d’entrée unique du front, il peut servir d’agrégateur. Peut-être que pour notre agenda, on avait besoin de la liste des événements futurs et également des événements où l’on est inscrit. Plutôt que de faire deux requêtes, le front n’en fera qu’une seule vers le BFF.

Avec cette mécanique, on voit rapidement plusieurs avantages :

• On sépare les logiques spécialisées. Il y a un BFF mobile, un BFF web, etc.
• On sépare la partie spécialisée de la partie généraliste. Il y a un backend qui ne subit pas les caprices du front.
• Un développeur mobile peut plus aisément sortir de son éco-système et effectuer des changements sur le BFF.
• On peut regrouper plusieurs ressources en une seule route, et réfléchir en termes de page, d’écran.
• On cache la complexité au front. Il n’y a pas à savoir s’il y a plusieurs services ou même s’il y a un partenaire externe.

Et notamment, ce qui nous intéresse particulièrement dans cette série d’articles, on déporte de la logique client (app mobile) sur un serveur distant (notre BFF). On peut donc modifier du comportement sans passer par les stores ! On aime :)

C’est tout de même une décision à peser dans l’équipe. Qui dit couche supplémentaire, dit une maintenance supplémentaire. Il y a une nouvelle brique qui doit évoluer et être déployée. Déléguer davantage au Back for Front augmente au passage les possibilités d’erreurs sur l’application - elle est plus permissive. On songera à monitorer plus en profondeur ce qu’il se passe dans l’application.

Série d’articles Mettre à jour une application mobile sans passer par les stores :

• #1 Pourquoi
• #2 Remote config, Feature Flag & co
• #3 Backend for Frontend (BFF)
• #4 Server-Driven UI
• #5 Interpréteur de code
• #6 Over-the-air update (OTA)
• #7 Les ressources
• #8 En résumé, mes options

Hors-série :

• Accélérer le temps de review App Store d’une application iOS
• Forcer la mise à jour d’une application mobile