Votre application est-elle lisible par Google et par les assistants IA ?

Votre application est-elle lisible par Google et par les assistants IA ?. Un dirigeant tape « développement application web » dans Google. Un autre demande à un assistant : « quel prestataire pour un outil de planning d'équipes ? ». Dans les deux cas, une réponse se forme avant qu'un humain n'ouvre votre site. Ce qui décide de votre présence n'est ni votre budget publicitaire ni votre position en page deux : c'est ce que la machine a réussi à lire dans votre application.

La réponse en quatre lignes

• Ce qui a changé : la demande entrante arrive de plus en plus par une réponse rédigée. Les fonctionnalités d'IA de Google n'exigent aucune optimisation spéciale pour y être repris, mais elles ne citent qu'une page indexée et affichable avec un extrait.

• Ce qu'une application doit exposer : son contenu dans le HTML que le serveur renvoie, pas seulement dans ce que le navigateur finit par afficher.

• Ce que nous livrons pour cela : un rendu côté serveur et des pages pré-rendues (Next.js sur notre propre site, Astro sur les projets récents), avec des faits vérifiables.

• Ce que cela pèse sur le devis : rien de plus. 3 900 €, 10 000 €, à partir de 20 000 €. Mais la décision se prend au cadrage.

Votre premier lecteur n'est pas un visiteur, c'est un système qui résume

Un moteur classique renvoyait une liste ; un assistant rédige une réponse et choisit les pages qu'il place en dessous. Il ne remplit pas un formulaire, ne devine pas une offre, ne parcourt pas votre menu. Il lit ce qu'il a pu récupérer, puis cite ce qu'il a lu.

Votre offre doit exister en texte : un catalogue sans intitulés, sans catégories, sans disponibilités écrites ne donne rien à citer.

Votre outil doit se présenter lui-même : une page qui n'est qu'un écran de connexion, ou un tableau qui se remplit après appel à une interface, ne dit rien à un système qui la visite sans compte.

Ce qu'une page doit porter pour être reprise dans une réponse

Le contenu doit être dans la première réponse du serveur

Google décrit un modèle qu'il connaît bien : les sites dont le HTML initial ne porte pas le contenu réel et qui attendent l'exécution du code pour l'afficher, qu'il doit alors mettre en file d'attente. Sa documentation ajoute deux précisions utiles : le rendu côté serveur ou le pré-affichage restent recommandés, et tous les robots n'exécutent pas JavaScript.

Traduit dans un projet : une disponibilité, un tarif ou une fiche produit écrits seulement après l'exécution de scripts sont des contenus qu'une machine peut manquer.

Une page doit rester indexable et reliée depuis l'intérieur du site

L'autre condition est plus ancienne et se perd dans les refontes : être atteignable. Le même guide recommande de rendre le contenu accessible par des liens internes. Nous l'appliquons sur les applications métier construites sur vos règles : chaque page renvoie à celle qui répond à la question suivante.

Le texte de notre propre site est servi avant qu'une ligne de JavaScript soit exécutée

Nous l'avons vérifié sur nous-mêmes, sans navigateur : interroger une page d'innotech-it.fr affiche déjà son titre, ses intertitres et son texte. Le site tourne sous Next.js en App Router, en rendu côté serveur, avec des pages pré-rendues : le contenu est dans la réponse, l'affichage vient ensuite.

Ce que cela change n'est pas théorique. Un assistant qui lit la même page trouve la même matière qu'un humain, sans dépendre d'une file d'attente de rendu. Une phrase tarifaire, un délai annoncé, une référence de véhicule peuvent être repris tels qu'ils sont écrits : à condition qu'ils y soient écrits.

Sur les projets récents, nous pré-rendons en Astro plutôt que de tout rejouer dans le navigateur

Sur nos projets récents, la page part pré-rendue : le HTML arrive complet, et le JavaScript ne reste que là où il est nécessaire (réservation, paiement, tableau de bord). Nous construisons cette couche en Astro, avec une architecture headless qui sépare le contenu de l'affichage. Trois fiches du portfolio portent cette pile, dont la refonte du site d'un cabinet d'avocats et celle d'une agence web.

Ce n'est pas un slogan pour autant. Quand un projet tourne sur WordPress et WooCommerce et qu'il tient la charge, nous ne le déplaçons pas : l'e-commerce alimentaire que nous avons porté jusqu'à 500 000 visites mensuelles tourne sur cette base, avec un travail de cache, de CDN et d'indexation. La question n'est pas la technologie du moment, mais ce que la page expose et à quelle vitesse elle répond.

Ce qu'une page d'outil métier doit montrer quand on l'interroge

Prenons un outil que nous avons livré. Sur DAN LOCATION, la plateforme de réservation expose un catalogue de véhicules et leurs disponibilités par période, la réservation et le paiement en ligne ; les contrats de location comme les factures y sont générés automatiquement par l'intelligence artificielle. Le tout tourne sous Next.js en rendu côté serveur, images servies par CDN.

Chacun de ces éléments est un fait qu'une machine peut lire et répéter : une catégorie de véhicule, une période disponible, un point de retrait. L'essentiel est que ces informations soient dans la page et non seulement dans la base : une réservation possible mais invisible pour un système ne vous ramène rien. Nous branchons ces automatisations sur le processus métier plutôt que sur un module loué — une IA reliée à vos règles de contrats et de facturation.

Une fiche projet qui accepte une vidéo se reprend mieux qu'un PDF figé

Sur nos fiches projet, la vidéo est prévue : une adresse YouTube ou Vimeo est normalisée puis intégrée dans la page, au milieu d'un portfolio parcourable, et non dans un document à télécharger. Ce qui se cite n'est pas la vidéo, c'est le texte qui l'entoure : ce que le projet devait résoudre, ce qui a été construit, ce qui a été mesuré.

Une fiche produit réduite à un PDF joint n'offre ni titre lisible, ni paragraphe à reprendre. La même information écrite dans la page se reprend et se vérifie.

Ce qu'un chiffre publié déclenche, et ce qu'un superlatif ne déclenche jamais

Un chiffre daté et vérifiable traverse une réponse d'assistant ; un adjectif s'y dissout. Sur l'e-commerce alimentaire Food By Box, le site a atteint 500 000 visites mensuelles en deux ans — chiffre publié dans notre étude de cas, avec la base technique et le travail de référencement qui l'ont produit.

Google publie de son côté les effets mesurés de cette exigence de clarté : les pages balisées en données structurées affichent des taux de clic supérieurs, +25 % chez Rotten Tomatoes sur 100 000 pages converties, +82 % chez Nestlé pour les pages présentées en résultats enrichis.

Aucune de nos pages ne porte de superlatif non prouvé : « solution innovante » n'est pas un fait reproductible, ni une donnée vérifiable pour un dirigeant. Nous écrivons ce qui est installé, où, et depuis quand.

Ce que cela change sur vos demandes entrantes — et ce que nous ne mesurons pas encore

Beaucoup de prestataires y vont d'une estimation ; nous préférons être précis. La part des demandes entrantes qui arrive par un assistant et non par une liste de résultats n'est pas mesurée chez nous à ce jour : [À VÉRIFIER — proportion des demandes issues des assistants IA, non instrumentée sur nos projets ; nous ne publions pas un chiffre que nous ne pouvons pas prouver.]

Ce que nous observons est vérifiable : une demande qui arrive après une réponse rédigée ne se comporte pas comme une visite de navigation. Elle arrive avec une question déjà formulée — un périmètre, un délai, un budget. Une page qui annonce un prix et un volume de travail la reçoit mieux préparée qu'un formulaire de contact seul. C'est le rôle que jouent notre grille publiée et deux ans de livraisons documentées.

Ce chantier ne coûte pas une ligne de plus, il se décide au cadrage

Nous ne facturons pas cette exigence comme un module : elle se joue dans deux décisions du cadrage, le rendu de la page et la rédaction de son contenu, prises avant la première ligne de code.

Notre grille le reflète : 3 900 € pour un site ou une boutique mono-vendeur, 10 000 € dès qu'il faut tenir plusieurs canaux ou parler à votre logiciel de gestion, à partir de 20 000 € pour une plateforme ou un produit vendu par abonnement, avec six mois de maintenance inclus. Ces montants et le détail de ce qui est livré sont publics. L'architecture et le prototype, qui verrouillent ce choix, sont livrés en trois à sept jours.

Le code, la base et le dépôt vous appartiennent à la livraison, installés sur votre infrastructure : votre application reste exposée aux outils que vous décidez. Et si elle devient un produit vendu par abonnement, vous gardez la main sur ce qu'elle montre.