REX Technique : refonte web avec Stitch, ChatGPT et Gemini

Ce retour d'expérience part d'un objectif très concret : créer le site de ma société X10.

Ou le re-re-re-créer.

C'est un récit technique, sans fantasme.

Le résultat est visible ici : https://x10-solutions.fr/

Pourquoi ce retour d'expérience ?

Je suis une fois de plus tombé sur une publication LinkedIn racoleuse : "12 agents Claude pour réécrire mon application pendant que je prends mon café".

Les contenus du type entretiennent une confusion entre démonstration rapide, site jetable et produit réellement exploitable.

Pourtant, avec un peu de recul et de connaissance, on comprend vite la supercherie : le temps de configuration, l'ajustement du contexte et des prompts, les tests, l'industrialisation, l'optimisation, etc. ont nécessité des heures de travail. Sans compter l'expérience nécessaire.

La réalité est que l'application en question n'est encore une fois qu'un projet personnel, non commercialisé, dont la quantité de code est bien inférieure à celle d'une application professionnelle concrète. Cela soulève d'ailleurs une question fondamentale : après la réécriture complète par votre agent, êtes-vous absolument certain de la qualité du livrable ? Avez-vous la garantie qu'aucune faille, ou même un cheval de Troie, n'a été introduit ?

L'IA en soi n'est pas le problème. Le véritable enjeu réside dans le manque de cadre, de réflexion critique et de perspective d'ingénierie. On assiste à un déplacement du problème : l'IA prend en charge les tâches simples (menaçant ainsi les postes juniors), tandis que les seniors restants se concentrent sur de nouvelles tâches de contrôle, garantes de la qualité, de la sécurité, de la cohérence et de la maintenabilité du système.

Précision importante : pour ce projet, je n'ai utilisé les IA que via leurs interfaces web (ChatGPT, Gemini, Stitch). Je n'ai pas utilisé d'agents autonomes ou intégrés à l'IDE pour la génération du code. Ce sujet, bien plus vaste, sera traité dans un prochain article.

Les objectifs

Les objectifs étaient clairs dès le départ : créer un site au design simple, avec une UX sobre, des informations complètes, d'excellent SEO technique, des scores Lighthouse presque à 100 de partout, des données structurées schema.org complètes et cohérentes, et une landing Google Ads claire et honnête.

En résumé, ce qu'un client est en droit d'attendre quand il paye pour un site vitrine.

Dans cette optique, j'ai aussi intégré une section "blog". Il ne s'agit absolument pas de copier Wordpress, mais plutôt de disposer d'un outil simple pour générer des pages de contenu. C'est l'unique objectif.

Le contexte : Hype vs Réalité (30 minutes)

L'IA ne connait rien. Ni de moi, ni de mon activité, ni de mes attentes. Il est essentiel que je fournisse des informations sur mon entreprise, car elles ne peuvent pas les deviner. C'est ce qu'on appelle le contexte.

Étant donné que l'objectif concerne mon activité principale, je gagne beaucoup de temps : il me suffit de rassembler et de synthétiser mes documents, puis de mettre en forme pour former un bon contexte IA. En revanche, si vous devez élaborer le contexte pour un client, cela sera bien plus long.

Mon compte ChatGPT est déjà configuré avec beaucoup de contexte persistant : profil, niveau d'exigence, ton attendu, contraintes techniques, manière de travailler. Pour ce site, j'ai créé un "projet" intégrant la présentation de X10, son positionnement, les objectifs du site, la stack technique, les contraintes SEO et le ton éditorial, etc.

J'ai reproduit cette approche avec les Gems dans Gemini. Cependant, l'expérience m'a montré que ce système de "projet" donnait de moins bons résultats. Je l'ai expérimenté sur d'autres sujets, tels que le droit, l'économie ou la comptabilité. J'ai souvent fini par retourner sur ChatGPT. À ce sujet, je trouve l'interface de Gemini bien moins intuitive que celle d'OpenAI pour rester concentré sur un projet. Nos discussions se mélangent. Cela manque d'organisation.

Il est important de noter que je n'ai pas cherché à optimiser systématiquement tous mes prompts. Je fournis le contexte soit en français, soit en anglais, selon mon intuition. Mon approche privilégie toujours une structure Markdown claire et l'utilisation de directives simples, allant droit au but, sans superflu. Je prévois d'écrire prochainement un article sur le context et le prompt engineering, sujets que je trouve très intéressants.

Une réserve s'impose : tout ce processus de copier-coller de contexte aurait pu prendre encore moins de temps si j'avais utilisé directement l'agent Gemini intégré à PHPStorm. L'intégration dans l'IDE permet de conserver le contexte du projet sans avoir à le réexpliquer ou à jongler entre les fenêtres.

Le périmètre (30 minutes)

Pour ce projet, j'inclus volontairement un périmètre large, comme si c'était un projet client. Cependant, je ne détaillerai pas ces points dans cet article. En fin de compte, il s'agit d'actions qui restent entièrement sous ma responsabilité et pour lesquelles l'IA n'apporte aucune aide .

• La configuration du nom de domaine chez OVH : x10-solutions.fr et x10-solutions.com
• L'hébergement chez OVH
• La configuration du serveur web Ubuntu, Nginx, etc.
• Les emails du domaine MX Plan chez OVH
• Le dépôt du code source chez GitHub
• Les clés d'échanges entre le serveur web et le dépôt GitHub
• Les comptes Google (Search Console, Analytics, Ads, Business)
• Les comptes sociaux nécessaires
• Etc.

Le design : Stitch (1h)

Stitch accélère la conception en générant des interfaces utilisateur (UI) pour les applications mobiles et web. Stitch génère les interfaces à partir d'un prompt et n'a pas, à ma connaissance, de gestion de contexte en dehors de la discussion en cours.

Comme j'ai tout mon contexte dans ChatGPT et dans Gemini, je les utilise pour générer des prompts Stitch afin de compenser mes limites actuelles en context/prompt engineering.

Je demande à ChatGPT ou Gemini de me créer un prompt en Markdown pour que Stitch crée (par exemple) la page d'accueil de mon site. Je travaille avec ChatGPT / Gemini pour que ce prompt soit le plus complet possible : couleurs, formes, attentes, textes, sections, etc.

Puis je colle le prompt généré dans Stitch.

Aucune optimisation.

Le prompt : ChatGPT vs Gemini

J'ai souvent trouvé les prompts de Gemini plus efficaces, du moins les résultats visuels étaient meilleurs. Cependant, je suis conscient que c'est subjectif et probablement lié à mon utilisation et à mes connaissances, peut-être même à un peu de chance.

En cours de route j'ai repéré que Gemini interprétait mes instructions enregistrées dans sa mémoire. Quand j'ai copié-collé celles de ChatGPT dans Gemini, elle les a reformulées et en a parfois changé le sens. Mélangeant par exemple "je" et "tu", changeant complètement le sens des directives.

Les prompts de ChatGPT donnent des résultats moins spectaculaires sur Stitch. Mais comme il gère mieux le contexte de mon entreprise, c'est quand même plus fiable dans une logique de projet structuré à long terme.

Ce que Stitch fait bien

Stitch propose une gestion de thème simple, utile pour maintenir une cohérence minimale. Ses rendus sont professionnels et largement suffisants pour la majorité des sites vitrines. En revanche, pour des interfaces d'applications web complexes, ses propositions UX me semblent moins fiables et moins adaptées à des workflows réels.

L'effet "WAHOU" est immédiat. La difficulté surgit lorsqu'il s'agit de conférer un sens véritable à cette production.

Le support natif des thèmes, qu'il s'agisse du mode "light" ou "dark", est géré de manière exemplaire. Cette fonctionnalité, essentielle dans le web moderne pour le confort visuel de l'utilisateur, est implémentée avec une esthétique professionnelle.

Le responsive design est un point fort majeur. Le screen s'ajuste avec une précision assez impressionnante sur smartphone, tablette, ou écran d'ordinateur de bureau. Ce niveau de qualité dans le responsive design surpasse ce que certains devs ont pu me livrer par le passé.

Autant de raisons pour revenir vers Stitch sans trop hésiter. Les performances globales et la qualité de la réalisation technique plaident largement en sa faveur.

Dette technique implicite

Depuis Stitch, si vous exportez les contenus, vous obtiendrez un fichier HTML, standalone, avec tout dedans. Stitch utilise TailwindCSS. Et vous verrez alors que tout est dupliqué sur chaque page que vous exportez. Il n'y a pas de variables, pas de templating, pas de factorisation. Aucune logique n'est en place pour découper le design et "simplement" reprendre les éléments récurrents des screens précédents. Rien ne vous assure non plus que d'un screen à l'autre Stitch n'a pas changé des sections sans rapport avec votre prompt.

La dette technique est immédiate.

C'est bien acceptable pour un MVP ou une landing. C'est problématique pour un site censé durer.

Prenez l'exemple suivant :

Lors de l'utilisation de Stitch pour générer des pages additionnelles, j'ai observé plusieurs comportements concernant l'en-tête (header) :

• Copie simple : L'en-tête reste parfois inchangé, il est simplement copié.
• Dérive visuelle : Une variation de couleur peut survenir (notamment entre les étapes 4 et 5).
• Réinvention partielle ou totale : L'outil peut réinventer des éléments spécifiques, comme le logo (entre 5 et 6), ou l'intégralité de l'en-tête (entre 6 et 7).

J'ai essayé de nombreuses méthodes pour stopper ces régénérations superflues. Inclure des consignes comme "NE PAS changer l'en-tête". Lui imposer de maintenir une section en lui donnant le code HTML à préserver. Mais aucune n'a fonctionné avec une fiabilité totale.

Génération de contenus

Stitch est capable de générer les contenus des pages : les titres, les textes, les accroches.

L'expérience s'est cependant révélée très insatisfaisante. Les textes générés, souvent peu naturels et manifestement calqués sur de mauvaises traductions de l'anglais, se sont avérés inadaptés au contexte, sans doute en raison de la technicité du sujet. Ils sont inutilisables en l'état.

Même lorsque mes requêtes contiennent précisément le texte à utiliser, Stitch ne peut s'empêcher de le reformuler. C'en est parfois ridicule. Prenez, par exemple, la première version générée pour la bannière du site :

Quelqu'un d'entre vous veux que je lui livre un "actif logiciel avec une transparence radicale" ?

Le piège

Le premier jet est souvent déterminant. Il est préférable de reprendre un projet à zéro en améliorant le prompt initial, plutôt que d'itérer sur un projet dont le premier résultat n'était pas optimal.

Comme le contexte de Stitch se limite à la discussion, les multiples demandes que vous ferez se rajouteront à sa liste de chose à retenir. J'ai l'impression que des petites itérations seraient plus pertinentes.

Il faut vous fixer une limite de temps pour interagir avec Stitch. La perfection est illusoire. Acceptez le résultat le moins "insatisfaisant", exportez le code, intégrez-le à votre projet et effectuez vous-même les ajustements nécessaires par rapport à vos attentes initiales. Sinon, c'est un jeu sans fin.

L'industrialisation : humaine (4h)

On a un beau design grâce à Stitch. Mais ça ne remplit pas nos objectifs. Cette phase d'industrialisation est le coeur du travail réel. Elle représente avec l'optimisation plus de 75 % du temps total passé sur le projet.

Le site a été intégré dans un socle Symfony 7, volontairement très épuré :

• Strict minimum du framework
• Aucun composant inutile
• Pas de surcouche

Pour la gestion des assets front, j'ai utilisé le bundle `pentatrion/vite-bundle` afin de faire le lien proprement entre Vite et le backend Symfony.

Pourquoi Symfony et pas WordPress ?

J'entends les grognements des développeurs de sites vitrine.

Le choix de WordPress est le plus fréquent, et je n'y vois aucun inconvénient. Cependant, mon expertise réside dans le développement d'applications métiers, ce qui écarte WordPress comme solution par défaut.

Bien que contre-intuitive pour un simple site vitrine, je privilégie une stack technique que je maîtrise à 100 %. Cette approche garantit une cohérence, une maintenabilité et une évolutivité optimales, même pour un projet de faible ampleur.

De plus, même si WordPress offre de bons outils, les fonctionnalités de SEO reposent souvent sur des plugins. Je tiens à garder le contrôle sur chaque ligne de code. Certes, je n'ai pas la main sur le code de Symfony, mais ma confiance dans cette communauté est bien supérieure (15 ans que je mets en production des applications en Symfony).

Effacer la future dette technique de Stitch

Plus de 50 % du code généré par Stitch a nécessité un refactoring manuel.

Les structures HTML sont globalement correctes. Mais dès que l'on veut travailler sérieusement les textes, l'UI ou l'UX, un nettoyage est indispensable.

Prenez cet exemple pour la page d'accueil :

<header>
    <div class="max-w-[1280px]"><!-- … --></div>
</header>
<section>
    <div class="size-[600px]"></div>
    <div class="max-w-[1200px]"><!-- … --></div>
</section>
<section>
    <div class="max-w-[1200px]"><!-- … --></div>
</section>
<section>
    <div class="max-w-[1000px]"><!-- … --></div>
</section>
<section>
    <div class="max-w-[1280px]">
        <div>
            <div class="max-w-[700px]"><!-- … --></div>
        </div>
    </div>
</section>
<section>
    <div class="max-w-[1100px]"><!-- … --></div>
</section>
<section>
    <div class="max-w-[900px]"><!-- … --></div>
</section>
<section>
    <div class="max-w-[1200px]"><!-- … --></div>
</section>
<section>
    <div class="max-w-[800px]"><!-- … --></div>
</section>

• Sur un layout vertical, chaque section définit sa largeur différemment (`width`, `max-width`, un container, deux containers, etc.). Cette logique se factorise facilement via des blocs Twig ou une classe CSS unique. Mais Stitch ne sait pas faire et répète des stratégie différentes. Dans ce cas, le layout n'a même pas les mêmes tailles maximales ; le visuel final est propre mais, dessous, tout n'est pas cohérent.
• Des éléments similaires (par exemple des boutons) sont codés différemment pour un rendu identique. Modifier un hover ou un thème dark impose alors des corrections multiples. C'est aussi une limite de TailwindCSS. De même, cela fonctionne bien par défaut. Cependant, le jour où vous réaliserez que le contraste du texte d'un bouton est insuffisant pour l'accessibilité, vous devrez revoir l'ensemble de vos boutons, alors même que chacun est codé de manière distincte.
• Stitch a tendance à intégrer directement des "valeurs en dur" dans son code (couleurs, tailles, etc.). Or, l'expérience montre que l'utilisation de valeurs en dur est fortement déconseillée. Si cela peut fonctionner ponctuellement pour une petite page ou un cas très spécifique, ce n'est plus viable lorsque l'application prend de l'ampleur. Il est impératif d'éviter que les développeurs ne copient/collent des codes couleurs ou ne gèrent les espacements en pixels de manière arbitraire. Pour garantir la cohérence et la maintenabilité, il est indispensable de définir un thème, une norme et un cadre de développement.

Sur un site vitrine, une légère variation des composants peut être tolérée. Sur une application métier, on exige une cohérence minimale de l'expérience utilisateur (UX).

Cette cohérence est très souvent assurée par la factorisation via l'utilisation de composants (comme ceux de React, par exemple). Cette approche est d'ailleurs recommandée par des frameworks comme Tailwind CSS qui le précise ici Reusing Styles.

Dépendances et performances

Stitch intègre les dépendances via des CDN (TailwindCSS, Google Fonts, scripts divers). Avec cette approche, viser un score Lighthouse maximal est impossible.

<script src="https://cdn.tailwindcss.com?plugins=forms,container-queries"></script>
<script id="tailwind-config">tailwind.config = { /* … */ };</script>
<link href="https://fonts.googleapis.com/css2?family=Inter:wght@300;400;500;600;700;800;900&display=swap" rel="stylesheet"/>
<link href="https://fonts.googleapis.com/css2?family=Fira+Code:wght@400;500&display=swap" rel="stylesheet"/>
<link href="https://fonts.googleapis.com/css2?family=Material+Symbols+Outlined:wght,FILL@100..700,0..1&display=swap" rel="stylesheet"/>

La solution mise en place :

• Suppression complète des CDN
• Installation des dépendances via npm
• Mise en place d'un build Vite (simple)
• Configuration de Tailwind pour analyser les fichiers Twig
• Purge du CSS pour ne charger que ce qui est utilisé
• Intégration locale des fonts (latin uniquement)
• Déplacement du CSS et JS inline dans le build

Résultat : dépendances maîtrisées, assets optimisés, meilleures performances, meilleur score Lighthouse et SEO.

L'optimisation : l'IA et l'humain (2h)

SEO et données structurées

ChatGPT s'en sort très bien pour le SEO technique. En lui fournissant simplement le HTML d'une page, il est capable :

• D'identifier des problèmes SEO évidents
• De proposer des améliorations pertinentes
• D'aider à remplir correctement les structures og, twitter, schema.org, etc.

L'objectif est resté simple et lisible. Sur-optimiser c'est aussi perdre du temps.

Il arrive régulièrement que l'IA évoque certaines règles SEO dans une conversation puis en génère de nouvelles dans une autre conversation. Cela impose un regard d'ingénieur pour analyser, généraliser et prioriser ce qui est demandé. Dans une conversation il me recommande d'ajouter "mentions" dans mes données structurées "WebPage". Le coup d'après, il me dit que ce n'est pas standard et que ce serait mieux de les retirer.

Il faut analyser ses propositions, les prioriser selon votre expérience et les généraliser pour tout votre site.

Les articles

Pour la rédaction de mes articles, j'utilise initialement des prompts structurés en Markdown qui définissent la trame attendue. Dans cette première étape, je me concentre sur le fond et les idées, en pré-rédigeant des éléments bruts, souvent lourds et mal écrits, sans me soucier de la qualité du style.

L'objectif de cette phase initiale n'est pas la rédaction finale, mais l'enrichissement de la structure Markdown. Je privilégie la structuration de l'information et l'identification des manques. Ça facilite grandement la modification, le déplacement ou la suppression de sections. La mise en forme est secondaire à ce stade.

Ensuite, je passe sur Google Docs pour la phase de révision et de fignolage. C'est là que j'opère une relecture attentive, améliore le style et donne du sens au texte. L'intégration de Gemini directement dans le document est une aide précieuse pour cette étape. J'attends d'ailleurs avec impatience que Google Docs supporte nativement le format de fichier Markdown.

Les images

La génération d'images reste décevante (à mon humble avis).

Voici un premier exemple concret : j'ai demandé à ChatGPT d'illustrer un article traitant du coût d'un projet, en me basant sur le texte de l'article et un prompt, il est vrai, peu détaillé. La proposition générée : des pièces de monnaie empilées sur un bureau, des panneaux d'alerte, et un homme se tirant les cheveux.

Fournir l'article comme simple contexte au prompt n'est clairement pas la meilleure approche.

Limites et pièges observés

Hallucinations et incohérences

Sur les contenus (ChatGPT et Gemini), cela reste rare si votre contexte est de qualité. Les problèmes sont surtout apparus lorsque le contexte était trop volumineux et mal structuré.

Sur les designs, c'est plus fréquent mais moins bloquant : dates erronées (copyright jamais à la bonne date), ajouts de sections jamais évoqués, instabilité visuelle d'un écran à l'autre.

<span class="font-bold text-white">X10</span> © 2024. Tous droits réservés.

Ce n'est pas toujours de l'hallucination au sens strict. C'est parfois simplement une volonté de générer à tout prix. Remplir des cases, sans trop savoir quoi y mettre.

Biais de confirmation

Je cherche volontairement à limiter ce biais dans mes personnalisations.

Je ne veux pas une validation gratuite. Je veux des contradictions, des corrections, des invalidations si nécessaire. Sans cela, on renforce une mauvaise idée au lieu de l'améliorer.

Les IA ont trop l'habitude de trouver que toutes vos idées sont géniales.

Dans vos paramètres, assurez-vous d'inclure des instructions pour que l'IA adopte une posture professionnelle, y compris en la chargeant de contredire, corriger ou signaler les erreurs si nécessaire.

Coût cognitif de validation

Pour le texte, la validation est simple : relire, corriger, faire corriger.

Pour le code, surtout en TailwindCSS, c'est plus coûteux. C'est verbeux et parfois difficile à relire sans connaître l'intention initiale. Paradoxalement, valider une génération IA peut demander plus d'effort que produire from scratch, car il faut :

• Comprendre ce qui a été fait
• Détecter les incohérences subtiles
• Déconstruire pour reconstruire proprement

Si vous adhérez à TailwindCSS alors Stitch vous aide quand même grandement à avancer.

Les moyens

J'estime avoir investi environ 8 heures, réparties sur une semaine.

Les outils principaux utilisés sont les suivants :

• ChatGPT Plus : 23 € / mois
• Gemini Pro : inclus dans l'offre Google AI Pro (2 TB) à 219.99 € / an
• Stitch : produit Google, inclus dans l'abonnement Gemini

J'utilise également un compte PHPStorm + JetBrains AI Pro (environ 250 € / an) qui m'aide à évoluer plus rapidement dans mon IDE. Par ailleurs, je commence à utiliser Claude (pour l'instant la version gratuite) afin d'obtenir des critiques plus détaillées sur certains aspects de mon développement.

Pour cet exercice il faut garder en tête que je suis Directeur Technique et Ingénieur en Sciences Cognitives expérimenté. Je conçois des applications web faites pour durer depuis plus de 15 ans, avec de vraies contraintes de performance, de sécurité, de SEO et d'évolutivité. Mes tarifs journaliers, variant de 600 € à 1000 € en fonction de la nature de l'activité, représentent rapidement une part significative du coût total du projet.

Il m'est malheureusement impossible de chiffrer le coût exact de cette « prestation » en raison d'un trop grand nombre de variables.

• Le contexte était facile à établir puisque x10 est mon entreprise.
• Les IA sont facturées au mois ou à l'année et peuvent être utilisées pour d'autres tâches.
• Mon TJM (Taux Journalier Moyen) correspond à celui d'un CTO, non d'un développeur.
• Les coûts des domaines et emails sont faibles chez OVH (moins de 10 €).
• L'hébergement est effectué sur un serveur dédié existant mutualisant les sites de plusieurs clients.

Avec un profil de CTO très expérimenté, le coût reste élevé pour un site dit vitrine, même avec des scores Lighthouse parfaits, un SEO technique propre et une base industrialisée saine.

L'IA ne rend pas la création de sites triviale. Elle déplace le coût : moins de production brute, plus de cadrage, de validation et d'ingénierie.

Conclusion

L'IA a été utilisée comme accélérateur, jamais comme substitut à l'ingénierie. Je n'envisage pas que des agents Claude puissent générer l'intégralité de l'application à partir de User Stories. Je suis d'ailleurs sceptique quant à la faisabilité d'une telle approche : pour une application web très complexe, la richesse du contexte serait excessive et les temps de génération trop longs pour produire des évolutions fiables et pérennes.

L'IA n'a pas supprimé mon travail. Elle a supprimé les temps morts, les hésitations inutiles et le syndrome de la page blanche. Il y a toujours un élément à ajouter, à critiquer, à améliorer ou à jeter. On reste en permanence dans l'itération plutôt que dans l'inertie.

L'IA agit comme un catalyseur pour éliminer les blocages entre les métiers. Je ne suis plus dépendant des livrables des autres équipes (textes marketing, maquettes graphiques, retours SEO). Je dispose de ma structure technique et l'IA intervient, tel un assistant rapide, pour prendre en charge les aspects relevant des autres spécialités.

Ce que l'IA a réellement accéléré :

• Le démarrage du projet
• La suppression du syndrome de la page blanche
• La production parallèle du contenu et de la structure
• L'exploration rapide d'options

Ce que l'IA ne remplace pas :

• La vision produit
• Les arbitrages techniques
• La cohérence globale
• La responsabilité finale

L'IA accélère l'exécution. Elle ne crée pas la direction.

Pour reproduire cette approche

Si vous êtes CTO ou tech lead et souhaitez reproduire cette démarche :

1. Investir d'abord dans le context/prompt engineering :
   Le temps passé à structurer le contexte est souvent plus rentable que de changer de modèle.
2. Ne jamais partir d'une génération sans phase d'industrialisation :
   Prévoir au moins 60 % du temps projet pour cette phase.
3. Valider systématiquement avec des outils tiers :
   Lighthouse, validateurs schema.org, tests manuels.
4. Accepter de jeter :
   Si une génération ne convient pas, recommencer coûte souvent moins cher que réparer.

Ces recommandations supposent un profil technique expérimenté. Sans ce prérequis, le risque de dette technique invisible devient très élevé. Cette démarche peut être reproduite pour des sites de clients, avec le même niveau d'exigence technique, le même cadrage et les mêmes garde-fous.

L'IA devient alors ce qu'elle devrait toujours être : un outil d'accélération maîtrisé, pas une promesse magique.

L'IA est un junior très rapide et les seniors n'ont jamais été aussi nécessaires pour cadrer, vérifier et industrialiser.