Accueil / Articles / Un flux de travail assisté par l’IA pour déployer un petit site web sur Cloudflare

Un flux de travail assisté par l’IA pour déployer un petit site web sur Cloudflare

Un flux de travail reproductible ainsi que des modèles de prompts pour concevoir, itérer et déployer un petit site à l’aide d’un assistant de codage IA, en utilisant les plans gratuits de GitHub et Cloudflare.

1981 mots

Un petit site d’information n’a plus besoin d’une longue phase de développement. Grâce à un assistant de codage basé sur l’IA qui s’occupe d’une grande partie de la mise en œuvre, une seule personne peut passer d’une idée approximative à du code source sur GitHub, des déploiements automatiques via Cloudflare et un domaine personnalisé en ligne en environ une demi-journée de travail concentré. La partie difficile passe alors de l’écriture du code à la décision de ce que l’on souhaite et à la fourniture de retours précis sur le résultat obtenu. Ce guide décrit ce flux de travail étape par étape, avec des modèles de prompts que vous pouvez adapter pour les phases de conception, de logo, d’évaluation et d’itération, et il indique clairement où cette approche cesse d’être appropriée.

Partez de l’objectif, pas d’un framework

La première question qui vient naturellement à l’esprit d’un développeur est de savoir quel stack utiliser : React, Next.js, un générateur de sites statiques ou autre chose. Lorsqu’un assistant peut générer la majeure partie de l’implémentation, cette question devient beaucoup moins importante qu’une autre, plus simple : quelles sont réellement les fonctions du site ?

Pour une première version d’un site personnel ou de consultation, la réponse peut être concise. Les visiteurs doivent comprendre ce que représente le site, pouvoir trouver ses articles et analyses, ainsi savoir comment entrer en contact. Cela constitue un périmètre complet. Le fait de l’écrire d’abord offre à la fois à vous et au modèle un critère clair pour chaque décision ultérieure, et empêche la première version de se transformer en un projet de refonte complet.

Lorsque vous n’avez pas de conception en tête

Beaucoup de gens commencent sans spécifications de conception, et ce n’est pas un problème. Au lieu d’utiliser des maquettes, décrivez l’expérience que vous souhaitez : par exemple, professionnelle, moderne, sobre, spacieuse et axée sur la technologie, sans pour autant avoir l’air futuriste pour le plaisir. L’assistant transforme cette description en une première esquisse visuelle.

Dès que quelque chose apparaît à l’écran, les retours deviennent faciles, car vous réagissez à quelque chose de concret plutôt que d’imaginer des choses :

  • Le logo ne correspond pas à la marque.
  • L’image de bannière est coupée.
  • Une section semble trop encombrée.
  • Une partie de la page doit être cachée pour l’instant.

Cette série de réactions constitue le processus de conception. Vous n’avez pas besoin de vocabulaire spécialisé en design, seulement la capacité de remarquer ce qui ne va pas et de le dire.

Le cycle de retours est plus important que la première demande

Il n’existe pas de prompt parfait unique. La première réponse a pour but de vous fournir quelque chose sur quoi réagir. Les instructions suivantes deviennent plus précises et ciblées : corriger le logo, ajuster le cadrage de la bannière, masquer les sections inachevées, renommer les éléments de navigation, tester les liens, vérifier le layout mobile.

La qualité provient de plusieurs séries courtes et spécifiques plutôt que d’une seule demande volumineuse. De plus, ces séries courtes facilitent la détection du moment où le modèle a modifié quelque chose que vous n’aviez pas demandé.

Un prompt de référence pour la première version

Un prompt d’ouverture utile décrit le projet, puis demande au modèle de proposer un design et d’en justifier les choix avant de générer du code. Un modèle peut inclure ces éléments :

  • Le nom de la marque, de l’entreprise ou du projet.
  • L’objectif : ce que le site doit vous permettre d’accomplir.
  • Le public cible : à qui il s’adresse.
  • Le message principal que le visiteur doit retenir dans les 15 à 20 premières secondes.
  • La direction visuelle, telle que professionnelle, minimaliste, haut de gamme, créative ou axée sur la technologie, ainsi que le choix entre un fond clair, sombre ou neutre.
  • Attentes de base : typographie propre, espaces suffisants, hiérarchie visuelle claire et un layout fonctionnel sur les téléphones.
  • Une déclaration honnête indiquant que vous n’avez pas encore choisi les couleurs, les polices ou la structure de la page.
  • Puis demandez au modèle de proposer, en fonction du but et du public cible :

    1. Une palette de couleurs.
    2. Une direction typographique.
    3. Une structure pour la page d’accueil.
    4. Un concept pour la section principale.
    5. La navigation.
    6. Les sections de contenu recommandées.
    7. Les appels à l’action.
    8. Le style visuel global.

    Terminez en lui demandant d’expliquer le design proposé et pourquoi il convient au public avant d’écrire du code, et de générer la première version fonctionnelle uniquement une fois que vous aurez approuvé cette direction. Séparer la proposition de l’implémentation est l’étape clé : il est bien moins coûteux de rejeter une palette décrite en texte que de la retirer du CSS généré.

    Traitez le logo comme une tâche à part entière

    Un logo doit également fonctionner en dehors du site : sur les profils sociaux, dans des diapositives et dans des documents. Le fait de le mélanger aux instructions relatives au site a tendance à produire quelque chose adapté uniquement à l’en-tête ; accordez donc à la création de la marque une demande distincte.

    Demandez un concept de logo simple, minimaliste, contemporain, professionnel et distinctif, qui reste reconnaissable même à petite échelle. Indiquez les supports où il doit être utilisé : sites web, avatars sur les réseaux sociaux, présentations, documents, ainsi que sur des arrière-plans clairs et sombres. Décrivez brièvement l’idée que représente la marque, puis demandez :

    1. Un concept visuel.
    2. Une orientation typographique.
    3. Une palette de couleurs.
    4. Une idée d’icône ou de monogramme.
    5. Une version pour des arrière-plans clairs.
    6. Une version pour des arrière-plans sombres.
    7. Une explication sur la raison pour laquelle le design convient à la marque.

    Ajoutez une contrainte explicite pour éviter des illustrations ou symboles complexes nécessitant de fines détails, car ceux-ci deviennent illisibles à la taille d’un favicon.

    Laissez l’assistant s’occuper de la mise en œuvre tout en restant concentré sur l’intention initiale

    Lorsque la direction a été définie, un assistant de codage (ChatGPT et Codex, dans le scénario d’où provient ce flux de travail) peut s’occuper de la majeure partie de l’implémentation. L’avantage est que les instructions restent au niveau de ce que vous souhaitez obtenir, plutôt que d’indiquer quel fichier et quelle ligne modifier :

    • Diviser le bandeau en deux.
    • Commenter ces sections pour l’instant.
    • Rénommer ce bouton.
    • Faire en sorte que ce bouton affiche la section correspondante.
    • Adapter le logo à l’œuvre originale.

    Enregistrez le domaine tôt et continuez à développer localement

    Enregistrer un domaine est rapide : recherchez, vérifiez la disponibilité, enregistrez et payez. Le rendre entièrement utilisable peut prendre plus de temps. Dans le scénario décrit ici, il a fallu environ 24 heures avant que tout ne soit résolu comme prévu ; le délai observé dépendra du registraire et de la propagation DNS.

    Cette attente n’a pas besoin d’entraver le développement. Continuez à créer et à tester en utilisant une version préliminaire locale grâce à un cycle itératif : modifier, visualiser, examiner, corriger, tester à nouveau. Travailler localement signifie également que les expériences inachevées ne sont jamais mises en ligne publiquement, et décrire les changements au niveau global vous évite de chercher dans plusieurs fichiers pour ajuster des lignes individuelles.

    Utilisez le modèle comme outil de révision, et non seulement pour créer

    Lorsque la première version est prête, demandez à l’assistant de la critiquer. L’instruction de révision doit lui assigner un rôle, l’empêcher de redessiner tout le contenu et exiger des résultats prioritaires et concrets.

    Priez-le d’examiner une capture d’écran en tant que designer senior UI et UX, afin d’identifier, sans redessin inutile, les principales opportunités d’amélioration :

    • Le layout : les espacements, l’alignement et l’équilibre visuel global.
    • L’hiérarchie et le type de texte : la clarté avec laquelle l’œil est guidé, le choix des polices et la lisibilité.
    • La cohérence : les couleurs et les éléments de marque sur toute la page.
    • La réactivité sur des écrans plus petits.
    • Les appels à l’action : le fait que chacun soit évident et clairement formulé.

    Demander que les constatations soient classées, et que chacune indique ce qui semble faible, pourquoi c’est important et exactement quoi changer. Limiter cela aux modifications qui améliorent de manière significative le professionnalisme et l’utilisabilité. C’est cette dernière phrase qui empêche l’évaluation de se transformer en simple liste de préférences esthétiques.

    C’est lors des itérations que se fait le plus gros du travail

    Après la conception initiale, très peu de travail consiste à créer quelque chose de nouveau. Presque tout porte sur l’amélioration de ce qui existe déjà, et des instructions courtes et précises sont les plus efficaces dans ce cas. Un modèle d’itération fiable ressemble à ceci :

    • Une liste numérotée des modifications spécifiques souhaitées, une par ligne.
    • Une instruction claire de ne pas redessiner les sections non pertinentes et de conserver tout ce qui fonctionne déjà.
  • Une liste de vérification que le modèle doit exécuter après les modifications : vérifier la mise en page sur ordinateur, vérifier la mise en page mobile, s’assurer que les liens de navigation fonctionnent, confirmer que chaque bouton mène à la bonne destination, s’assurer qu’il n’y a rien de caché ou de coupé par erreur, et signaler tous les problèmes restants qu’il détecte.
  • L’instruction relative à la préservation mérite d’être soulignée. Les assistants ont tendance à « améliorer » le code adjacent en corrigeant ce que vous avez demandé, et une contrainte explicite réduit cette dérive. La liste de vérification automatique ne remplace pas votre propre revue, mais elle permet de détecter d’éventuelles dégradations avant même que vous ne les voyiez.

    De la prévisualisation locale à un site en ligne avec GitHub et Cloudflare

    Lorsque le site fonctionne localement, transférez son code source vers un répertoire GitHub. GitHub vous offre un historique des versions ainsi qu’un moyen sûr de revenir en arrière sur toute modification apportée par l’assistant.

    Ensuite, connectez ce répertoire à Cloudflare afin que chaque mise à jour vers le répertoire déclenche une compilation et un déploiement automatiques. Dès lors, la publication se résume simplement à effectuer des commits et des pushes. Pour un petit site informatif, le plan gratuit de Cloudflare suffit dans ce cas ; vérifiez les limites du plan actuel en fonction de vos besoins.

    Lorsque le domaine est actif et que ses enregistrements DNS sont configurés, associez le nom de domaine personnalisé au projet déployé. À ce stade, en saisissant le nom de domaine dans un navigateur, vous verrez le site en ligne.

    Quel est le coût, et dans quels cas cela ne convient pas

    Pour ce type de projet, les coûts d’exploitation sont modérés :

    • Enregistrement du domaine : environ 12 dollars par an dans ce cas.
    • GitHub : gratuit.
    • Cloudflare : le plan gratuit était suffisant.
    • Outils d’IA : selon le coût de votre abonnement à ChatGPT ou à un autre assistant.

    En dehors de la souscription à l’assistant, le domaine constitue essentiellement le seul coût d’infrastructure.

    Cette approche n’est pas adaptée à toutes les applications. Tout ce qui implique des paiements, des données personnelles sensibles, une authentification complexe, des bases de données ou des environnements réglementés nécessite une ingénierie appropriée : modélisation des menaces, revue du code par quelqu’un qui comprend chaque ligne, tests et surveillance opérationnelle. Cependant, pour les portefeuilles, les pages d’accueil, les sites de conseil, les prototypes et les sites de contenu simples, la barrière à l’entrée est considérablement plus faible qu’auparavant.

    Ce que l’assistant décide et ne décide pas

    L’assistant prend en charge une grande partie de l’exécution : rédaction et modification de code, transformation des retours sur la conception en modifications concrètes, résolution des problèmes visuels et explication des étapes techniques peu familières. Plusieurs décisions restent cependant strictement humaines :

    • Ce que le site doit représenter.
  • Quel contenu est important.
  • Si le design visuel est approprié.
  • Quand la première version est suffisamment bonne pour être mise en ligne.
  • Cela déplace le goulot d’étranglement. La question limitante cesse d’être de savoir si l’on peut techniquement créer le site et devient plutôt de savoir si l’on peut déterminer clairement ce que l’on souhaite. L’obstacle lié à la mise en œuvre diminue, mais le besoin de jugement persiste.

    Points clés

    • Définissez l’objectif, le public cible et le message principal avant de choisir toute technologie.
    • Demandez au modèle de proposer et de justifier un design avant d’écrire du code, et approuvez explicitement la direction à suivre.
    • Gérez le logo séparément afin qu’il fonctionne sur tous les supports, et non seulement dans l’en-tête du site.
    • Faites appel à des cycles d’itération courts et précis, avec la contrainte de « conserver tout le reste » ainsi qu’une liste de vérification personnelle.
    • Utilisez l’assistant à la fois comme critique et comme outil de création, avec des retours hiérarchisés et concrets.
    • Collez le code sur GitHub et laissez Cloudflare le déployer à chaque mise à jour, afin que le contrôle de version et l’hébergement soient automatiques.
    • Réservez cette approche légère aux sites à faible risque. La valeur réside dans la manière dont les éléments s’intègrent dans un flux de travail unique : vous contrôlez l’objectif, le jugement et l’approbation, l’assistant s’occupe de l’exécution, GitHub gère l’historique et Cloudflare assure la publication.