Votre app fonctionnera-t-elle encore dans trois ans ?

Le jour du lancement, tout va bien : vous avez vu votre app tourner. Elle est en ligne, les premiers utilisateurs la téléchargent, tout répond. La question qui compte vraiment ne se pose pas ce jour-là.

Elle se pose bien plus tard — le matin où quelqu'un vous écrit pour signaler que quelque chose ne marche plus. Entre les deux, trois ans ont passé, pendant lesquels vous n'avez rien touché.

Votre app, elle, n'a pas changé d'une virgule. Le monde autour d'elle, si. C'est là qu'est le paradoxe : une app peut cesser de fonctionner sans qu'une seule ligne n'ait bougé à l'intérieur.

Quatre mouvements, pour l'essentiel. Les stores durcissent leurs règles — déclarations de confidentialité, versions minimales, politiques de permissions. Les systèmes abandonnent des fonctions en chemin, et en rendent d'autres obligatoires. Certaines choses ont une date : les certificats et certains identifiants de service expirent — le certificat SSL d'un domaine, par exemple. Et les données s'accumulent, jusqu'à ce que ce qui était instantané devienne poussif.

Pierre-Laurent a fait l'inventaire détaillé de ce qui se dégrade en silence, politiques des stores et délais à l'appui. Je ne vais pas le refaire ici. Ce qui m'intéresse dans cet article, c'est la question d'après : une fois qu'on sait tout ça, qui s'en occupe ?

Dire qu'une plateforme « s'occupe de la maintenance » est vague au point d'être creux. Le mécanisme réel tient en une phrase : le problème est corrigé une fois, au niveau de la plateforme, et chaque app en hérite à sa build suivante.

Quand une nouvelle exigence de confidentialité entre en vigueur, ce ne sont pas des milliers de créateurs d'apps qui lisent la documentation d'Apple chacun dans son coin. C'est une équipe, une fois, qui met à jour le moteur qui construit les apps. Quand un système abandonne une fonction, le composant concerné est réécrit une fois, au même endroit. Vous n'avez rien lu, rien migré, rien décidé.

Autant énoncer l'alternative, parce que c'est tout l'argument de construire sur une plateforme plutôt que de maintenir son propre code. Si c'est à vous de maintenir le code source de l'app — écrit par un développeur que vous avez recruté, ou généré à partir d'un prompt en une après-midi —, cette même phrase décrit votre après-midi. C'est à vous de remarquer que la règle a changé, de comprendre ce qu'elle exige, de modifier le code, de reconstruire, de re-soumettre. Personne ne l'a fait une fois pour tout le monde : c'est fait une fois pour vous, puis encore pour le changement suivant, et celui d'après. Produire une app est devenu remarquablement bon marché, et c'est une vraie bonne nouvelle. La maintenir à jour n'a pas bougé d'un pouce. Pierre-Laurent a détaillé cet écart.

Un point d'honnêteté, parce qu'il compte : cette veille n'attrape que ce qu'on a vu venir. Lire les règles avant qu'elles ne s'appliquent, réécrire un composant avant qu'un abandon ne devienne une panne, c'est un métier exercé en continu — pas une garantie automatique.

Tout ce qui précède vaut pour une app vivante, qu'on republie de temps en temps. Mais la vraie inquiétude est ailleurs, et personne ne la formule : j'ai laissé mon app de côté pendant deux ans. Est-ce qu'elle est perdue ?

Non. Et la raison tient à la façon dont le travail s'accumule : les correctifs attendent votre app, ils ne lui courent pas après. Une app qu'on ne touche pas ne se répare pas toute seule pendant la nuit — rien ne descend sur elle pendant qu'elle dort. Mais pendant ces deux ans, chaque changement de règle, chaque fonction abandonnée par iOS ou Android a été traité une fois, en amont, pour toutes les apps de la plateforme. Ce travail ne s'est pas évaporé parce que la vôtre était silencieuse. Il est là, empilé, et il l'attend.

La conséquence est très concrète : quand vous revenez, vous ne rattrapez pas deux ans à la main. Vous reconstruisez, et votre app ressort aux normes du monde d'aujourd'hui, pas de celui dans lequel elle est née. Se remettre à niveau n'est pas un chantier, c'est une build. Vous n'avez pas à savoir ce qu'il y avait dedans.

C'est exactement ce qui n'arrive pas quand c'est vous qui maintenez le code source. Rien ne s'est accumulé pour vous pendant qu'elle dormait. Deux ans de changements restent deux ans de changements, qui attendent que quelqu'un — vous, ou quelqu'un que vous payez — les reprenne un par un avant que l'app puisse repartir.

C'est la vraie réponse à la question posée par le titre, et elle tient en deux colonnes.

De notre côté : le moteur qui construit les apps, tenu à jour en permanence. La lecture des règles des stores avant qu'elles ne s'appliquent. La réécriture des composants avant qu'un abandon ne se transforme en panne. La chaîne qui envoie vos notifications. Le certificat SSL de votre domaine, renouvelé avant chaque échéance. Rien de tout cela ne vous demande une décision, ni même d'être au courant.

De votre côté, et personne ne peut le faire à votre place :

• Vos comptes développeur Apple et Google. Ils sont à votre nom — c'est ce qui fait que l'app vous appartient — et ils se renouvellent. Un compte expiré retire l'app des stores, quelle que soit la qualité de ce qu'il y a dedans.
• Les déclarations qui décrivent votre contenu et vos pratiques de données. Elles parlent de votre activité, pas de la nôtre : nous pouvons les préparer à partir des fonctions que vous avez réellement activées, pas décider à votre place ce que vous faites des données de vos utilisateurs.
• Le geste d'envoyer la mise à jour. Toute nouvelle version passe par la revue des stores : la plateforme prépare tout, vous déclenchez. Si ce dernier point vous pèse, GoodBarber Takes Care est l'option où nous soumettons les mises à jour aux stores à votre place.

La liste est courte. C'est volontaire — et chacune de ces lignes mérite son propre article, ce que fera cette série.

Le vrai bénéfice n'est pas technique : c'est du temps gagné. Les heures que vous ne passez pas à lire les notes de version d'Apple, à déchiffrer ce qu'est une déclaration de confidentialité ou à chercher pourquoi un certificat a expiré, vous les passez sur votre contenu, votre audience, votre activité.

C'est un bénéfice difficile à mettre en avant, parce qu'il ne se voit pas : quand il fonctionne, rien ne se passe. Aucune démonstration ne peut le prouver ; seul le temps le vérifie. C'est ce que la plateforme fait, discrètement, depuis 2011.

Si le détail technique vous intéresse, j'ai décrit ailleurs, du point de vue de l'ingénierie, ce qui casse vraiment en trois ans.

Le plus simple pour voir à quoi ressemble une app construite sur cette mécanique, c'est de commencer la vôtre : créer mon app avec GoodBarber.

Mon app fonctionnera-t-elle encore dans trois ans ?

Une app laissée strictement intacte finit par prendre du retard sur son environnement, et c'est vrai partout. La différence tient à ce que coûte le rattrapage : sur une plateforme qui absorbe les changements, les correctifs ont déjà été faits et attendent votre app. La remettre à niveau est une reconstruction, pas un chantier.

J'ai laissé mon app de côté pendant deux ans. Est-ce qu'elle est perdue ?

Non. Rien ne s'applique à une app pendant qu'elle dort, mais tout le travail fait entre-temps au niveau de la plateforme l'attend : à la reconstruction suivante, elle ressort aux normes actuelles. C'est là toute la différence avec une app dont vous devez maintenir le code source, où rien ne s'est accumulé pour vous.

Qui est responsable de quoi entre la plateforme et moi ?

La plateforme prend en charge ce qui est commun à toutes les apps : le moteur qui les construit, la conformité aux règles des stores, le remplacement des composants abandonnés, l'infrastructure des notifications. Vous gardez vos comptes développeur Apple et Google, les déclarations qui décrivent votre contenu, et la décision de publier les mises à jour.

Faut-il des compétences techniques pour maintenir une app dans la durée ?

Non, et c'est le point : la partie qui en demande est faite une fois, en amont, pour toutes les apps. Ce qui reste de votre côté relève de l'administratif et de l'éditorial — renouveler des comptes, décrire votre contenu, choisir quand publier — pas du code.

Pourquoi mon app est-elle plus lente qu'à son lancement ?

Le plus souvent, rien n'a cassé : le volume a changé. Ce qui était instantané sur un petit catalogue demande plus de travail quand il a grossi pendant des années. C'est le seul des quatre mouvements qui vient de votre succès plutôt que de l'extérieur — et le sujet d'un prochain article de cette série.