Le message est paru la veille du lancement prévu

Le 31 juillet, le compte de Google AI Studio a publié une note brève pour remercier les quelque 800 000 personnes qui avaient préréservé son application mobile sur iOS et Android. Cette note n'annonçait pas un lancement. C'était une annulation. L'application autonome ne sortirait pas du tout.

Les comptes rendus du même jour situaient la sortie prévue au 1er août, ce qui place la décision dans les dernières vingt-quatre heures d'un calendrier de livraison. Les préréservations étaient ouvertes sur Google Play et sur l'App Store depuis la conférence développeurs I/O de cette année, soit assez longtemps pour qu'un très grand nombre de personnes enregistrent leur intérêt et pour que, dans certaines organisations, cette application soit déjà inscrite dans un plan.

On cite d'ordinaire les chiffres de préréservation comme la preuve qu'un lancement est acquis. Celui-ci a été cité dans l'avis annonçant que le lancement était annulé. C'est ce renversement qu'il faut retenir.

Google a nommé la raison, et ce n'était pas le produit

Les annulations arrivent d'habitude enveloppées dans rien du tout. Celle-ci est venue avec une explication, et l'explication est d'une franchise inhabituelle. "Plutôt que de vous demander de télécharger encore une application, nous avons décidé d'adopter une approche entièrement différente : une approche où les applications émergent naturellement, au fil de vos conversations quotidiennes avec Gemini", a écrit l'entreprise. Elle s'associe pour cela à l'équipe de l'application Gemini, sur mobile comme sur ordinateur.

Relisez la première partie. L'objection ne vise ni la qualité de l'application, ni sa maturité, ni son coût, ni son accueil. L'objection vise le téléchargement. Dans la même note, l'entreprise a indiqué qu'il était clair que les gens souhaitent créer des logiciels en déplacement, ce qui revient à reconnaître explicitement que la demande mesurée était réelle.

La séquence est donc la suivante : demande confirmée, produit achevé, lancement annulé. Rien là-dedans n'est un échec de produit. C'est une décision sur le lieu où doit vivre une capacité, prise par ceux qui possèdent la surface de distribution et non la fonction.

C'est la surface séparée qu'il faut surveiller

La plupart des acheteurs évaluent le risque de la feuille de route d'un fournisseur avec des chiffres d'adoption. Est-ce que quelqu'un l'utilise, est-ce que cela progresse, le fournisseur s'est-il engagé publiquement. Ce sont trois instruments inadaptés, car ici les trois étaient au vert et aucun n'a pesé. Huit cent mille inscriptions, c'est à peu près le signal de demande le plus bruyant qu'une équipe produit puisse produire avant de livrer, et il a perdu.

L'instrument qui aurait fonctionné est structurel et s'applique en une minute. Posez-vous deux questions sur toute capacité de fournisseur dont vous dépendez. Vous parvient-elle par une surface qui lui est propre, c'est-à-dire sa propre application, sa propre console, son propre portail ou sa propre ligne de facture ? Et cette surface accomplit-elle un travail que le produit phare du fournisseur pourrait vraisemblablement absorber ? Ce qui répond oui aux deux est candidat à la consolidation, quelle que soit sa réussite du moment.

Ce n'est pas une prédiction annonçant la disparition de toutes ces fonctions. C'est une manière de nommer le risque que vous portez réellement. Quand un fournisseur consolide, la capacité survit le plus souvent et la surface non, si bien que la perturbation à anticiper n'est pas la perte d'une fonction. C'est une migration forcée qui suit le calendrier du fournisseur et non le vôtre.

Ce qui a survécu indique où le fournisseur est sérieux

La version web d'AI Studio n'a pas été touchée. Google a déclaré continuer d'y investir et l'a positionnée pour celles et ceux qui veulent aller d'une idée à une instruction, puis à une activité. Ce cadrage est la moitié utile de l'annonce, car il sépare les deux surfaces par l'intention : l'une s'adresse à qui construit et elle est restée, l'autre faisait double emploi avec une tâche que l'assistant principal savait déjà faire et elle a disparu.

Pour une équipe qui planifie, la lecture est donc plus étroite que "on ne peut pas compter sur Google ici". Elle est que la surface pour développeurs portait l'engagement et que la surface proche du grand public portait le risque. Qui comptait bâtir un flux de travail sur l'application mobile aurait traversé la semaine sans rien changer en le bâtissant sur la version web et sur les interfaces qui la soutiennent.

Pour les équipes européennes, il y a un point supplémentaire. Une capacité qui déménage dans une application d'assistant général ne change pas de lieu de manière neutre, car les conditions, les droits d'administration et le traitement des données d'un assistant grand public ne sont pas automatiquement ceux d'un produit pour développeurs. Quand un fournisseur annonce un tel déplacement, demandez cette comparaison par écrit avant de planifier autour du nouveau domicile, et non après.

La surface va dans le contrat, pas dans la présentation

Le changement pratique est modeste. Lorsqu'une capacité de fournisseur entre dans un plan, nommez la surface de livraison dans le document qui engage, et pas seulement la capacité. "Création d'applications disponible dans l'application mobile du fournisseur" et "création d'applications disponible" sont deux engagements différents, et un seul survit à une consolidation. Si le fournisseur refuse de nommer la surface, ce refus est lui aussi une information, et elle coûte moins cher maintenant.

Le coût de l'omission n'a rien de spectaculaire, et c'est précisément pour cela qu'on l'omet. Une équipe qui aurait engagé 20 000 euros de temps interne sur un chantier mobile ce trimestre n'a perdu ni la capacité ni l'argent. Elle a perdu le calendrier, et elle l'apprend avec un jour d'avance par une publication sur un réseau social plutôt qu'avec un préavis inscrit dans un contrat. C'est une perte petite, évitable et parfaitement reproductible.