Blog FabLrc

Catégorie : outils

  • AWS en 2026 : guide complet des services cloud pour développeurs

    AWS en 2026 : guide complet des services cloud pour développeurs

    Introduction

    En 2025, Amazon Web Services (AWS) détenait 32 % du marché mondial du cloud computing — c’est Synergy Research qui le dit. Ça fait réfléchir, non ? Pourtant, quand on débute dans le développement, l’infrastructure cloud peut ressembler à un mur de sigles absurdes. EC2, S3, Lambda… Concrètement, à quoi ça sert, tout ce bazar ?

    Ce guide est pour vous. On va décortiquer les services AWS en 2026 avec des exemples concrets, des astuces, et zéro jargon marketing. Pas de bla-bla. On parle comme on code : direct, efficace.

    L’objectif ? Vous donner les clés pour démarrer sur AWS sans vous noyer. Parce que le cloud computing, ce n’est pas juste un mot à la mode. C’est un levier pour développer, déployer et scaler vos apps.

    Et puis 2026 arrive vite. La conteneurisation, le serverless, le DevOps sont devenus le quotidien. La virtualisation aussi a évolué. Même la sécurité cloud n’est plus optionnelle — honnêtement, elle ne l’a jamais été.

    Quand j’ai commencé, j’ai lancé une instance EC2 sans comprendre la facturation. 80 euros en une nuit. Une bonne leçon. Depuis, j’ai appris à maîtriser les bases.

    Alors, prêt à plonger dans AWS ? On commence par un cas concret qui vous parlera.

    Cas pratique et retour d’expérience – Un projet web en 2026

    Prenons un exemple. Vous êtes développeur freelance. Vous devez lancer une API pour un client – une plateforme de réservation en ligne. Budget serré, délais courts. Comment monter ça rapidement sur AWS sans vous ruiner ?

    En 2026, le réflexe n’est plus de louer un serveur dédié. On pense serverless et infrastructure cloud. Voici le stack typique que j’ai utilisé sur un projet similaire en mars dernier :

    • Stockage cloud : Amazon S3 pour les images et fichiers statiques. Simple, pas cher, scalable.
    • Base de données cloud : Amazon DynamoDB (NoSQL) pour les réservations. Pas de gestion de serveur, temps de réponse inférieur à 10 ms.
    • Calcul : AWS Lambda pour l’API. Chaque requête déclenche une fonction. On paie à l’exécution, pas à l’heure.
    • API Gateway pour exposer les endpoints.
    • Cognito pour l’authentification des utilisateurs.

    Résultat : infrastructure entièrement serverless, déployée en deux jours, facture mensuelle : 12 € pour les premiers mois.

    Schéma d'exemple d'une infrastructure serverless avec les services AWS

    Mais attention, tout n’est pas rose. La courbe d’apprentissage est réelle. La virtualisation avec EC2 reste utile pour les workloads prévisibles. Et la sécurité cloud demande une vigilance constante – IAM policies, encryption, logs. Un oubli, et c’est la porte ouverte aux fuites.

    Ce qui a changé en 2026, c’est la maturité des outils. DevOps est intégré nativement : CodePipeline, CodeBuild, et des intégrations avec GitHub Actions — j’ai d’ailleurs partagé mon workflow agentique de l’idée à la production qui utilise ces services.

    Le vrai plus ? La conteneurisation avec ECS ou EKS permet de déployer des microservices sans s’enfermer. Et le serverless s’étend au stockage et aux bases de données – direction le « full serverless ».

    Un chiffre : selon une étude de l’INSEE sur l’adoption du cloud en 2024, 68 % des entreprises françaises utilisaient au moins un service cloud. En 2026, ce devrait être 85 %. La migration cloud n’est plus une option. C’est une nécessité, à dire vrai.

    Regardons ça de près.

    Comparer les approches – Serverless vs EC2, lequel choisir ?

    Vous avez deux grandes familles chez AWS : les services gérés (serverless) et les instances virtuelles (EC2). Chacune a ses forces.

    EC2 : vous louez une machine virtuelle. Vous gérez l’OS, les mises à jour, le scaling. C’est flexible, mais ça demande du travail manuel. Pour des applications avec des pics prévisibles, ça reste pertinent. Exemple : un site e-commerce avec des sessions utilisateurs lourdes.

    Serverless (Lambda, DynamoDB, S3) : vous écrivez du code, AWS s’occupe de l’exécution, du scaling, de la disponibilité. Idéal pour les APIs, les traitements par lots, les microservices. Moins de contrôle, mais moins de maintenance.

    Dans la pratique, je recommande souvent de commencer par le serverless. C’est plus simple pour apprendre les concepts du cloud computing. Quand vous butez sur ses limites (cold starts, timeout, coût pour des requêtes longues), passez sur EC2 ou Fargate.

    Et justement, si vous utilisez déjà des conteneurs, regardez ECS ou EKS. La conteneurisation avec Docker est un standard – j’explique pourquoi dans mon article Pourquoi j’utilise Docker sur la majorité de mes projets.

    Un tableau rapide :

    CritèreServerlessEC2
    Coût fixeNon (pay-per-use)Oui (réservation possible)
    ScalabilitéAutomatiqueManuelle ou auto-scaling
    MaintenanceFaibleÉlevée
    Contrôle OSAucunTotal

    Choisir, c’est renoncer. Mais en 2026, la tendance est claire : le serverless domine pour les nouvelles apps. La virtualisation reste utile pour les workloads legacy ou très spécifiques. C’est discutable, mais c’est mon constat.

    Points clés à retenir

    Avant de conclure, voici l’essentiel pour bien démarrer avec AWS en 2026 :

    • Commencez par un compte gratuit AWS – 12 mois de services limités (750h d’EC2, 5Go S3, etc.). Parfait pour expérimenter sans risque.
    • Maîtrisez les trois piliers : EC2 (calcul), S3 (stockage cloud), RDS (base de données cloud). Même en serverless, ces services sont la fondation.
    • Adoptez le serverless pour vos APIs – Lambda + API Gateway + DynamoDB forme un trio ultra-efficace pour des apps légères.
    • Sécurisez dès le début – IAM roles, chiffrement S3 (SSE-S3), CloudTrail logs. Un mauvais paramétrage peut coûter cher.
    • Utilisez les outils DevOps – CloudFormation ou Terraform pour l’infrastructure as code. Automatisez vos déploiements avec GitHub Actions ou CodePipeline.
    • Gardez un œil sur la facture – activez les budgets et alertes. L’infrastructure cloud peut déraper si vous laissez des ressources allumées.
    Image des services AWS

    Voici une liste des services clés à explorer en priorité :

    1. EC2 – instances virtuelles pour du calcul classique.
    2. S3 – stockage d’objets scalable et durable.
    3. Lambda – exécution de code sans serveur.
    4. DynamoDB – base NoSQL gérée.
    5. RDS – bases relationnelles (MySQL, PostgreSQL) gérées.
    6. ECS / EKS – conteneurs (Docker, Kubernetes).
    7. CloudFront – CDN pour distribuer le contenu rapidement.
    8. IAM – gestion des accès et sécurité.
    9. VPC – réseau privé virtuel pour isoler vos ressources.
    10. Route53 – service DNS pour gérer vos noms de domaine.

    Une source utile : Cloud 2026 : l’IA propulse le marché au-delà des 500 Md$. Les chiffres montrent une croissance continue – 2026 sera l’année où le cloud devient le nouveau « on premise ».

    Et n’oubliez pas : le cloud computing n’est pas une fin en soi. C’est un outil. L’important, c’est de résoudre des problèmes métier. AWS vous donne une boîte à outils immense. À vous de choisir les bons pour chaque tâche. (Et croyez-moi, j’en ai testé des mauvais.)

    Conclusion

    Un dernier point qui m’a surpris : en 2026, la plupart des développeurs que je rencontre n’utilisent encore que 10 % des services AWS. Les autres restent inexploités, par méconnaissance ou par peur de la complexité. C’est dommage.

    Alors voici ma question pour vous : quel est le premier service AWS que vous allez tester ce soir ? Pas besoin de tout apprendre d’un coup. Choisissez un problème simple – héberger une image, exécuter une fonction toutes les heures – et résolvez-le avec un seul service.

    L’AWS que je vous ai présenté ici n’est qu’une porte d’entrée. Derrière, il y a des centaines de services pour le machine learning, l’IoT, le big data… Mais ça, ce sera pour une prochaine fois.

    En attendant, lancez-vous. Créez un bucket S3. Déployez une Lambda. Et si vous bloquez, souvenez-vous : la communauté AWS est immense, les documentations sont claires, et vous avez déjà fait le plus dur – comprendre les bases.

    Bon code, et à bientôt sur le cloud.

  • Mon Workflow « Agentique » : De l’idée à la production

    Mon Workflow « Agentique » : De l’idée à la production

    Il y a quelques mois encore, j’utilisais l’IA comme un simple assistant : un super moteur de recherche ou un générateur de snippets. Mais les choses ont changé. Vite.

    Aujourd’hui, je ne « chat » plus vraiment avec mon IDE. Je collabore avec des Agents.

    Récemment, VSCode (ou Cursor si vous voulez) a intégré nativement la gestion des agents. Couplé à des modèles de raisonnement comme Claude Sonnet 4.5 ou Gemini Pro 3, et à la puissance des MCP (Model Context Protocol), ma façon de développer une application, de l’idée au déploiement, a été totalement transformée.

    Voici comment je développe mes applications aujourd’hui, étape par étape, sans jamais quitter mon éditeur.

    Using agents in Visual Studio Code

    Le Setup : Donner des super-pouvoirs à l’IA

    Avant d’écrire la moindre ligne de code, il faut équiper l’agent. Un modèle d’IA, aussi puissant soit-il, est limité par sa date de connaissance (training cut-off) et son isolement. Pour pallier cela, j’installe des MCP (Model Context Protocol).

    C’est le standard qui permet à l’IA de se connecter à des outils externes. J’en utilise principalement deux :

    • Context7 : C’est mon « bridge » vers la connaissance temps réel. Il permet à l’agent de consulter les documentations officielles les plus récentes. Fini le code React déprécié ou les hallucinations sur des API qui n’existent plus.
    • ChromeDevTools : Permet à l’agent de « voir » et debugger ce qui se passe dans le navigateur via la console ou des screenshots qu’il prend lui même.
    • Supabase, Stripe, MongoDB : J’utilise Supabase pour plusieur de mes projets, un MCP existe permettant aux agents de l’utiliser « nativement ». C’est la même chose avec pas mal de technologies actuelles, je vous invite à les utiliser selon les projets, vos agents n’en seront que plus efficaces !

    La Mémoire du Projet : Le dossier .github/instructions

    C’est mon secret pour éviter que l’IA ne devienne amnésique ou incohérente au bout de 30 messages.

    L’IA a une fenêtre de contexte limitée. Plutôt que de répéter « N’oublie pas qu’on utilise Tailwind » à chaque prompt, je crée un dossier .github/instructions à la racine de mon projet. Les agents VSCode lisent ces fichiers systématiquement avant de répondre.

    J’y place généralement :

    • tech_stack.md : La liste de mes technos (Next.js, Supabase, Shadcn/ui…).
    • arch.md : L’architecture du projet (les connexions avec les APIs, les dossiers du projets, …)
    • project_rules.md : Mes principes de design (DRY, composition over inheritance, gestion des erreurs).
    • plan.md : L’état d’avancement(roadmap) du projet (on y reviendra).

    C’est la mémoire à long terme de mon assistant.

    Phase d’Idéation : Challenger le concept

    Tout commence par une discussion, mais pas n’importe laquelle. J’active le modèle Gemini Pro 3, GPT 5.2 ou Claude Opus 4.5 (pour leur capacité de raisonnement supérieure) et je lance un prompt de challenge.

    Voici un exemple de prompt :

    Objectif : obtenir une analyse complète, structurée et objective d’une idée d’application pour décider de sa viabilité commerciale et stratégique.

    Instructions pour l’IA :
    Tu es un analyste de marché expert, combinant des compétences en stratégie, business model, étude de concurrence, finance, tarification, estimation des coûts, et validation de produit. Je te fournis ci-dessous une idée d’application ; tu dois évaluer sa viabilité sur le marché réel, en étant objectif et précis.

    1. Résumé de l’idée (à remplir)
    Nom de l’application :
    Description succincte :
    Problème que l’application résout :
    Public cible :

    2. Analyse de marché

    • Estime la taille du marché adressable (TAM/SAM/SOM) avec des données ou chiffres du secteur (sources publiques, tendances).
    • Décris les tendances du marché, croissance, demandes émergentes, et si le problème existe dans la réalité.
    • Identifie les indicateurs de demande, comme volume de recherche, communautés/plateformes où le problème est discuté, signaux d’intérêt (forums, social), etc.

    3. Concurrence

    • Liste les principaux concurrents directs et indirects (produits/services similaires).
    • Compare leurs offres, fonctionnalités, positionnement, forces et faiblesses.
    • Évalue les barrières à l’entrée (propriété intellectuelle, effets réseaux, coût d’acquisition, licences).

    4. Business Model & Tarification

    • Propose plusieurs modèles de monétisation plausibles (SaaS, freemium, abonnement, commission, publicité, etc.).
    • Pour chaque modèle, suggère plages de prix réalistes basées sur le marché actuel.
    • Estime les marges unitaires (par utilisateur/transaction) avec hypothèses de coûts variables et fixes.

    5. Coûts & Temps de Développement

    • Estime le coût de développement (MVP, version 1) : main-d’œuvre, tech stack, design, tests, infrastructure.
    • Donne une plage de durée réaliste de la phase MVP jusqu’à une première version exploitable (en semaines/mois).
    • Identifie les ressources ou compétences nécessaires (dev, product, marketing, support).

    6. Acquisition & Distribution

    • Propose des canaux efficaces pour acquérir les premiers utilisateurs et tester rapidement l’offre (ex. pubs, référencement, réseaux pro, partenariats).
    • Estime un coût d’acquisition client (CAC) réaliste selon les canaux.
    • Donne une stratégie de go-to-market progressive (phase beta, early adopters, scaling).

    7. Scénarios Financiers

    • Présente 3 scénarios (pessimiste / réaliste / optimiste) avec :
      • Nombre d’utilisateurs sur 12 mois
      • Revenus estimés
      • Coûts (fixes + variables)
      • Point mort financier (break-even)

    8. Risques & Opportunités

    • Identifie risques majeurs (technique, réglementaire, marché, concurrence) et stratégies pour les atténuer.
    • Détaille opportunités supplémentaires (extensions de produit, marchés adjacents).

    9. Recommandation Finale

    • Sur une échelle de 1 à 10, donne une note de viabilité commerciale globale.
    • Résume conditions pour poursuivre (ex : validations à faire, données manquantes, prochaines étapes).

    Format de réponse attendu :
    Réponse structurée par section, avec chiffres ou sources quand c’est possible, hypothèses indiquées clairement, et recommandations concrètes (pas seulement théoriques).

    L’agent me force à affiner mon tir avant même de coder. Une fois l’idée validée, on passe à la structure.

    Planification : Le mode « Plan » de VSCode

    Une fois l’idée validée, il va falloir planifier le développement de celle-ci pour en faire une application fonctionnelle (ou dans un premier temps un bon MVP). Pour ça, vous pouvez utiliser le mode « plan » dans VSCode. C’est une fonctionnalité native de VSCode que j’adore. Je ne saute pas dans le code.

    Ici, je demande à l’agent de rédiger le PRD (Product Requirements Document). On définit ensemble :

    1. Le MVP (Minimum Viable Product) : Qu’est-ce qu’on livre en premier ?
    2. Les User Stories : « En tant qu’utilisateur, je veux… »
    3. L’Architecture : Base de données, API, Authentification.

    L’agent génère un fichier PLAN.md. Ce fichier servira de boussole pour tout le reste du développement. Je le place donc dans mon dossiers « .github/instructions« 

    Voici un exemple de prompt pour le plan :

    Objectif :
    Construire un plan global, fonctionnel et non technique d’une application déjà validée sur le marché, décrivant précisément ce que fait l’application, pour qui, et comment les utilisateurs interagissent avec elle, jusqu’à obtenir une vision complète et cohérente du produit.

    Rôle de l’IA :
    Tu es un Product Manager senior spécialisé en conception d’applications (web / mobile / SaaS).
    Ton objectif est de transformer une idée validée en un plan fonctionnel détaillé, clair et structuré, sans écrire de code ni entrer dans des choix techniques.

    Tu dois :

    • Identifier les zones floues ou ambiguës
    • Poser des questions ciblées et utiles quand des informations manquent
    • Construire le plan progressivement, en itérant avec l’utilisateur
    • T’arrêter uniquement lorsque le plan est complet, cohérent et exploitable

    1. Contexte de départ (fourni par l’utilisateur)

    Nom de l’application :
    Objectif principal de l’application :
    Problème utilisateur résolu :
    Cible principale (utilisateurs) :
    Plateforme(s) envisagée(s) : (ex : mobile, web, desktop)

    2. Méthode de travail (obligatoire)

    • Commence par résumer ta compréhension du produit en quelques phrases
    • Identifie immédiatement :
      • Ce qui est clair
      • Ce qui est incomplet ou ambigu
    • Pose des questions avant d’aller trop loin si nécessaire

    ⚠️ Ne fais pas d’hypothèses critiques sans validation.
    Pose des questions plutôt que d’inventer.

    3. Structure attendue du plan fonctionnel final

    Tu devras produire, une fois toutes les informations réunies, un plan contenant au minimum :

    A. Vision Produit

    • Proposition de valeur principale
    • Objectifs du produit (court / moyen terme)
    • Règles fondamentales (ce que l’app fait / ne fait pas)

    B. Typologie des utilisateurs

    • Types d’utilisateurs (ex : visiteurs, utilisateurs inscrits, admins, etc.)
    • Droits et capacités de chaque type
    • Parcours général de chaque type d’utilisateur

    C. Parcours Utilisateur (User Journeys)

    • Découverte / arrivée sur l’app
    • Inscription / onboarding
    • Utilisation principale (cœur de valeur)
    • Actions récurrentes
    • Sortie / désengagement

    D. Fonctionnalités Clés

    Pour chaque fonctionnalité :

    • Objectif utilisateur
    • Description fonctionnelle (ce que ça permet de faire)
    • Déclencheur (quand / pourquoi l’utilisateur l’utilise)
    • Résultat attendu

    ⚠️ Pas de technique, pas de code, pas de stack.

    E. Règles Métier & Logique Fonctionnelle

    • Limitations
    • Cas particuliers
    • Conditions d’accès à certaines fonctionnalités
    • Interactions entre fonctionnalités

    F. Gestion des Contenus & Données (fonctionnel)

    • Types de données manipulées (sans schéma technique)
    • Qui crée quoi, qui voit quoi, qui modifie quoi
    • Logique de cycle de vie des contenus

    G. Notifications & Interactions

    • Types de notifications
    • Déclencheurs
    • Objectifs (engagement, information, rappel, etc.)

    H. Monétisation (si applicable)

    • Ce qui est gratuit vs payant
    • Déclencheurs de paiement
    • Parcours utilisateur lié à la monétisation

    I. Administration & Modération

    • Fonctionnalités nécessaires pour gérer l’app
    • Actions possibles côté admin
    • Contrôles et règles

    4. Processus itératif obligatoire

    • À chaque étape :
      • Si une information manque → pose une ou plusieurs questions précises
      • Attends la réponse avant de continuer
    • Reformule régulièrement pour valider la compréhension
    • Ne considère le plan terminé que lorsque toutes les sections sont complètes

    5. Critère de fin

    Le travail est terminé lorsque :

    • Le plan peut servir de base à un cahier des charges fonctionnel
    • Un designer ou un développeur peut comprendre ce que doit faire l’application
    • Aucune fonctionnalité majeure n’est floue ou implicite

    Commence maintenant par :

    1. Résumer ta compréhension du projet à partir des éléments fournis
    2. Lister les informations manquantes
    3. Poser les premières questions nécessaires

    Développement : L’Agent aux commandes

    C’est ici que la magie opère. Je passe en mode « Agent » avec Claude Sonnet 4.5. Ce modèle est redoutable pour le code.

    La règle d’or : Les Micro-tâches

    Je ne dis jamais « Crée toute l’application ». C’est le meilleur moyen d’obtenir du code spaghetti.

    Je découpe le travail :

    « Implémente la User Story #1 : La page de Login avec Supabase Auth. »

    Exécution et Auto-correction (Self-Healing)

    L’agent va :

    1. Lire mes instructions (.github/instructions).
    2. Générer le code des composants.
    3. Lancer des commandes terminal.

    C’est là que c’est fort : si je lui demande de lancer un npm run lint ou un test et que ça échoue, l’agent lit l’erreur et se corrige lui-même. Il itère jusqu’à ce que la tâche soit verte.

    Grâce au MCP Context7, s’il a un doute sur une nouvelle fonction de Next.js 16, il va lire la doc officielle avant d’écrire le code, m’évitant des heures de debugging.

    Sécuriser l’avancée : Git et Tests

    Travailler avec des agents va vite, très vite. Parfois trop. Pour ne pas perdre le contrôle :

    1. Tests automatisés : J’exige de l’agent qu’il crée un test unitaire pour chaque feature critique. C’est mon filet de sécurité pour m’assurer que les nouvelles modifications ne cassent pas ce qui marchait 5 minutes avant.
    2. Commit Atomique : Dès qu’une micro-tâche est validée et que les tests passent -> Git Commit.Si l’agent part en vrille à l’étape suivante (ça arrive), je fais un simple rollback. Git est mon bouton « Sauvegarde ».

    Déploiement : L’Agent DevOps

    Une fois le MVP prêt, je ne change pas de méthode. Je demande à l’agent :

    « Prépare le déploiement sur Vercel. Vérifie que les variables d’environnement sont bien configurées dans le projet et génère le Dockerfile si nécessaire. »

    L’agent interagit avec les CLI, prépare les configs, et je n’ai plus qu’à valider le push sur GitHub qui déclenchera la CI/CD.

    Conclusion

    Ce workflow a radicalement changé ma productivité. Je ne tape plus autant de code « boilerplate », mais je passe plus de temps à concevoir, vérifier et guider.

    VSCode, avec ses modes natifs (Plan, Agent, Edit) et la puissance des modèles comme Claude Sonnet 4.5, devient plus qu’un éditeur : c’est un véritable cockpit de pilotage.

    Et vous, vous avez testé les MCP ? Dites-moi en commentaire quel est votre setup !

  • VS Code : Comment synchroniser votre configuration entre tous vos ordinateurs

    VS Code : Comment synchroniser votre configuration entre tous vos ordinateurs

    Si comme moi vous jonglez entre plusieurs machines — un MacBook pour les déplacements, une tour sous Windows à la maison, ou peut-être un laptop fourni par un client — vous connaissez forcément cette friction.

    Vous installez une super extension ou vous peaufinez un raccourci clavier sur votre machine principale, et le lendemain, en ouvrant VS Code sur votre autre poste… c’est la frustration. Il manque la moitié de vos outils, le thème n’est pas le bon, et votre productivité en prend un coup.

    Pendant longtemps, la solution consistait à copier-coller des fichiers JSON ou à utiliser des extensions tierces parfois instables. Mais c’est du passé. Aujourd’hui, je vous montre comment utiliser la synchronisation native de VS Code pour avoir un environnement de développement unifié, où que vous soyez.

    Fini le bricolage, place au natif

    Il y a quelques années, l’extension « Settings Sync » (celle avec l’icône rouge) était la référence. Elle utilisait des Gist GitHub pour stocker nos configs. C’était ingénieux, mais c’était du bricolage.

    Microsoft a finalement intégré cette fonctionnalité directement dans le cœur de l’éditeur (depuis la version 1.48). C’est plus rapide, plus fiable et surtout, beaucoup plus simple à configurer.

    Ce qui est synchronisé (et ce qui ne l’est pas)

    Avant d’activer le bouton magique, voici ce que VS Code va propager sur vos machines :

    • Paramètres : Votre fichier settings.json (police, zoom, formatage, etc.).
    • Raccourcis clavier : Vos bindings personnalisés.
    • Extensions : La liste de vos plugins (et leur état activé/désactivé).
    • Snippets : Vos morceaux de code réutilisables.
    • État de l’interface : La disposition de vos panneaux, votre thème, vos icônes.

    Ce qui reste local (et c’est tant mieux) : les chemins de vos exécutables spécifiques à la machine (comme le path vers un binaire PHP ou Python s’il diffère d’un OS à l’autre).

    Le tutoriel : Activer la synchronisation en 3 clics

    La procédure est triviale, mais autant la faire proprement. Commencez par l’ordinateur qui possède votre configuration idéale.

    1. Ouvrez VS Code.
    2. Cliquez sur la roue dentée Gérer (Manage) tout en bas à gauche.
    3. Cliquez sur Activer la synchronisation des paramètres… (Turn on Settings Sync).
    Le menu de la roue dentée propose l'option "Turn on Settings Sync"

    Une fenêtre va s’ouvrir vous demandant ce que vous souhaitez synchroniser. Par défaut, tout est coché. Je vous conseille de tout laisser tel quel pour une expérience vraiment « miroir ».

    Ensuite, cliquez sur le bouton Se connecter & Activer. VS Code vous proposera deux choix :

    • Compte Microsoft
    • Compte GitHub

    Personnellement, j’utilise mon compte GitHub. Une fois l’autorisation donnée dans votre navigateur, VS Code va uploader votre configuration dans le cloud.

    Sur votre deuxième ordinateur

    C’est là que la magie opère. Ouvrez VS Code (qui est peut-être vierge ou mal configuré).

    Répétez la même opération : Roue dentée > Activer la synchronisation > Connexion (avec le même compte).

    VS Code va détecter une configuration existante dans le cloud. Il va télécharger vos extensions, appliquer votre thème et vos raccourcis. En moins de 30 secondes, vous vous retrouvez avec votre environnement familier.

    Gérer les conflits sans panique

    Que se passe-t-il si vous modifiez un paramètre sur l’ordi A et un autre sur l’ordi B alors qu’ils sont hors ligne ?

    Lors de la reconnexion, VS Code va détecter un conflit. Il ne va rien écraser bêtement. Il vous présentera une vue de comparaison (diff view) similaire à celle de Git, vous demandant si vous voulez garder la version Locale, la version Cloud, ou fusionner les deux manuellement. C’est propre et sécurisé.

    Pour aller plus loin : Les Profils

    C’est une nouveauté récente qui change la donne. Si vous faites du développement Web le jour et du Rust ou du C++ le soir, vous n’avez pas forcément besoin des mêmes 50 extensions chargées en permanence.

    VS Code permet maintenant de créer des Profils (Roue dentée > Profils > Créer un profil). Vous pouvez avoir un profil « Work » et un profil « Perso ».

    La bonne nouvelle ? Settings Sync gère aussi les profils. Vous pouvez donc retrouver votre profil « Dev React » parfaitement configuré sur tous vos ordinateurs, sans polluer votre installation avec des outils inutiles.

    Conclusion

    Si vous n’avez pas encore activé cette fonctionnalité, foncez. C’est le genre de configuration « set it and forget it » qui offre un confort de vie incroyable. On change d’ordi, on se logue, et on code. C’est aussi simple que ça.

    N’hésitez pas à me dire en commentaire si vous utilisez des profils spécifiques ou si vous préférez tout garder dans une config globale !

  • Automatiser vos déploiements (CI/CD) avec GitHub Actions

    Automatiser vos déploiements (CI/CD) avec GitHub Actions

    Les pipelines CI/CD (Continuous Integration / Continuous Delivery) sont devenus un standard incontournable du développement moderne. Ils assurent la qualité du code et accélèrent la mise en production.

    GitHub Actions offre une solution puissante et native pour orchestrer ces pipelines directement depuis votre dépôt GitHub, sans avoir besoin d’outils externes complexes comme Jenkins.

    Comprendre le CI/CD en un coup d’œil

    Avant de plonger dans le code, rappelons les concepts :

    • Continuous Integration (CI) : C’est le filet de sécurité. À chaque modification du code (push ou Pull Request), on compile le projet et on lance les tests automatiquement.
    • Continuous Delivery (CD) : C’est l’automatisation de la livraison. Si la CI est validée (tests au vert), le code est automatiquement déployé sur un serveur de test ou de production.

    Le principe clé : Si le code échoue à la compilation ou si un test ne passe pas, le processus s’arrête immédiatement. On ne déploie jamais une erreur.

    GitHub Actions : Comment ça marche ?

    GitHub Actions fonctionne via des Workflows (fichiers YAML) situés dans le dossier .github/workflows/. Pour bien comprendre la structure, il faut connaître ce vocabulaire :

    Action : Un script réutilisable (ex: actions/checkout pour récupérer le code).

    Workflow : Le processus automatisé complet (ex: « Déploiement Production »).

    Event (on) : L’événement qui déclenche le workflow (ex: un push sur main).

    Job : Une série d’étapes exécutées sur un même serveur (Runner).

    Step : Une tâche individuelle (ex: lancer une commande npm install).

    Cas pratique : Mettre en place la CI (Tests)

    Voici un workflow classique pour une application Node.js. Il s’assure que le code est sain avant toute chose.

    name: CI Test

on:
  push:
    branches: [ "main" ]
  pull_request:
    branches: [ "main" ]

jobs:
  build-and-test:
    runs-on: ubuntu-latest # Le système d'exploitation virtuel

    steps:
      # Étape 1 : Récupérer le code
      - name: Checkout code
        uses: actions/checkout@v4

      # Étape 2 : Installer l'environnement
      - name: Setup Node.js
        uses: actions/setup-node@v4
        with:
          node-version: '20' # Toujours utiliser une version LTS récente
          cache: 'npm'       # Astuce : met en cache les node_modules pour aller plus vite

      # Étape 3 : Installation et Tests
      - name: Install dependencies
        run: npm ci # 'npm ci' est plus fiable que 'npm install' pour les pipelines
      
      - name: Run tests
        run: npm testLangage du code : YAML (yaml)

    Cas pratique : Le Déploiement (CD)

    Une fois le code validé, nous voulons le déployer. Pour cet exemple, nous utiliserons SCP pour copier les fichiers vers un serveur Linux classique.

    Sécurité avant tout : Ne mettez jamais de mots de passe en clair dans vos fichiers YAML. Utilisez les GitHub Secrets (Settings > Secrets and variables > Actions).

    name: Deploy to Server

on:
  push:
    branches: [ "main" ]

jobs:
  deploy:
    runs-on: ubuntu-latest
    # Optionnel : attendre que la CI passe avant de déployer
    # needs: build-and-test 

    steps:
      - name: Checkout code
        uses: actions/checkout@v4

      # Imaginez ici une étape de "Build" (ex: npm run build) qui génère un dossier dist/

      - name: Copy files to server
        uses: appleboy/scp-action@master
        with:
          host: ${{ secrets.SERVER_IP }}
          username: ${{ secrets.SERVER_USER }}
          key: ${{ secrets.SERVER_SSH_KEY }}
          source: "dist/"
          target: "/var/www/myapp"
          strip_components: 1 # Pour éviter de copier le dossier parent "dist"Langage du code : YAML (yaml)

    L’astuce Pro : Tester en local avec Act

    L’un des plus grands défis des pipelines CI/CD est le cycle « commit > push > attendre l’erreur > recommencer« . L’outil Act résout ce problème en vous permettant d’exécuter vos GitHub Actions localement via Docker.

    Pourquoi l’utiliser ?

    • Gain de temps immédiat (feedback loop rapide).
    • Pas de pollution de l’historique Git avec des commits « fix ci ».
    • Économie des minutes gratuites de GitHub Actions.

    Installation et utilisation :

    # Sur macOS
brew install act

# Lister les jobs disponibles
act -l

# Lancer le workflow complet
act
# Ou lancer un job spécifique
act -j build-and-testLangage du code : Bash (bash)

    Conclusion

    L’automatisation avec GitHub Actions n’est pas seulement un gain de temps, c’est une garantie de sérénité. En mettant en place ce pipeline :

    1. Vous détectez les régressions instantanément (CI).
    2. Vous déployez sans intervention manuelle risquée (CD).
    3. Vous sécurisez vos accès grâce aux Secrets.

    Commencez par un workflow simple de tests, puis ajoutez le déploiement une fois à l’aise. Votre « moi du futur » vous remerciera !

  • Gemini 3 Pro : Le nouveau modèle qui dépasse Claude Sonnet 4.5 ?

    Gemini 3 Pro : Le nouveau modèle qui dépasse Claude Sonnet 4.5 ?

    Dans mon travail de développeur, j’utilise régulièrement plusieurs modèles d’IA pour m’aider à prototyper, coder, déboguer ou simplement réfléchir à une solution. Parmi les plus performants du moment, deux se démarquent clairement : Gemini 3 Pro et Claude Sonnet 4.5.
    Ils sont tous les deux excellents, mais pas pour les mêmes raisons. Leur différence de “personnalité” a un vrai impact sur la manière dont je les utilise dans mes projets.

    Dans cet article, je partage mon analyse et surtout comment j’exploite chacun d’eux de manière efficace selon le contexte.

    Gemini 3 pro : puissance brute, multimodalité et créativité technique

    Quand j’ai besoin de transformer une idée en prototype concret, Gemini 3 Pro est souvent mon premier réflexe. Il excelle dans :

    Génération de code neuf et algorithmes complexes

    Gemini est impressionnant pour créer de nouveaux algorithmes, structurer des architectures ou générer rapidement des bases de code multi-fichiers.
    Il gère très bien les gros contextes (jusqu’à 1 million de tokens) et comprend des instructions longues ou ambiguës.

    Concrètement, je l’utilise pour :

    • créer des prototypes front/back rapidement,
    • concevoir des algorithmes optimisés,
    • générer des agents ou des pipelines complexes,
    • explorer des approches techniques ou des patterns avancés.

    Multimodalité avancée

    Un autre point fort : sa compréhension multimodale. Que j’envoie du texte, un schéma, une capture d’écran ou même une vidéo, il garde une cohérence globale.
    C’est un vrai atout pour analyser une interface, comprendre un bug visuel ou concevoir une structure d’application à partir d’un diagramme.

    Quand je préfère éviter Gemini

    Sur des sessions longues ou du raisonnement très étendu, Gemini a parfois tendance à dériver légèrement du sujet. Rien de dramatique, mais je sens qu’il fatigue plus vite que Claude.

    Claude sonnet 4.5 : fiabilité, focus et précision sur le code existant

    Claude Sonnet 4.5, c’est mon choix quand je veux de la stabilité et de la rigueur.

    Roi du débogage et du refactoring

    Claude excelle pour analyser une base de code existante, repérer des incohérences, corriger des bugs ou réécrire des modules sensibles.
    Son score SWE-Bench démonte clairement la concurrence sur les tâches de bug fixing et de code review.

    Je l’utilise principalement pour :

    • corriger des exceptions difficiles à tracer,
    • auditer un repo complet,
    • améliorer la lisibilité ou les performances,
    • réécrire du code legacy sans casser la logique métier.

    Une attention incroyable sur les longues sessions

    Là où Gemini peut perdre le fil après plusieurs dizaines d’échanges, Claude garde une constance presque surprenante.
    Pour une tâche de fond sur 2–3 heures, je ne me pose même pas la question : je lance Claude.

    Là où Claude est moins adapté

    Il est moins à l’aise que Gemini sur la multimodalité, et parfois un peu trop prudent dans ses suggestions de code.
    Pour innover ou explorer des idées radicalement nouvelles, Gemini reste meilleur.

    Cmment je décide lequel utiliser selon le contexte

    Pour créer une application de zéro

    Je pars presque toujours sur Gemini 3 Pro.
    Il me génère rapidement une architecture, du code multi-fichiers, du boilerplate propre, et il explore plusieurs approches si je le pousse un peu.

    Pour maintenir ou corriger une application existante

    Je passe à Claude Sonnet 4.5.
    Il identifie les problèmes plus vite, explique clairement ce qui cloche et propose des corrections fiables.

    Pour les tâches nécessitant du raisonnement long

    Claude est nettement plus stable.
    Si j’ai un gros audit technique ou un long raisonnement métier, je sais qu’il ne va pas diverger.

    Pour tout ce qui touche au visuel, aux schémas ou à la conception

    Gemini 3 Pro est largement devant grâce à sa multimodalité.

    Pour comparer deux approches ou rédiger une documentation

    Les deux s’en sortent bien, mais je trouve Claude plus clair, plus “posé” et plus régulier.

    Mon workflow idéal pour tirer le meilleur des deux

    Après plusieurs essais, j’ai fini par adopter un fonctionnement hybride :

    1. Prototypage initial → Gemini
      Il me génère la structure technique, les services, les composants, les endpoints…
    2. Stabilisation du code → Claude
      Je lui fais relire les fichiers, optimiser ce qui peut l’être, simplifier ce qui est inutile.
    3. Tests et débogage → Claude
      Il trouve des edge cases que je n’avais même pas envisagés.
    4. Documentation et synthèse → Claude
      Sa formulation est plus propre pour la doc technique.
    5. Itérations créatives / exploration → Gemini
      Quand j’ai besoin d’idées, de variantes ou de solutions alternatives.

    En combinant les deux, j’ai drastiquement réduit le temps passé à prototyper, corriger, documenter et améliorer mes projets.

    Conclusion

    Gemini 3 Pro et Claude Sonnet 4.5 ne sont pas en concurrence directe à mes yeux : ils se complètent parfaitement.

    • Gemini est le moteur créatif, rapide, multimodal et capable de générer des systèmes entiers.
    • Claude est l’expert rigoureux, précis et incroyablement fiable pour stabiliser et faire évoluer une base de code.

    Si je devais résumer :
    👉 Gemini pour créer.
    👉 Claude pour fiabiliser.

    C’est la combinaison qui, en tant que développeur, me fait gagner le plus de temps au quotidien.

  • Pourquoi j’utilise Docker sur la majorité de mes projets

    Pourquoi j’utilise Docker sur la majorité de mes projets

    Au fil des années, j’ai travaillé sur de nombreux projets — personnels, professionnels, petits, gros, parfois même un peu chaotiques. Et s’il y a bien une chose que j’ai apprise, c’est que gérer les environnements de développement peut vite devenir un cauchemar.
    Combien de fois ai-je voulu partager un projet qui fonctionnait très bien chez moi mais pas chez les autres ?
    C’est précisément pour éviter ce genre de situations que j’utilise Docker, presque systématiquement aujourd’hui.

    La portabilité avant tout

    L’un des plus grands atouts de Docker, c’est la portabilité.
    Quand je lance un projet, je veux être sûr que le code que j’écris fonctionnera exactement de la même manière sur mon poste, sur celui d’un collègue, sur le serveur de staging ou en production.

    Avec Docker, plus besoin de configurer manuellement une base de données, un serveur web ou un runtime particulier. Tout est défini dans des fichiers (Dockerfile, docker-compose.yml) et versionné avec le reste du projet.
    Résultat : il suffit d’un simple docker-compose up pour tout démarrer, quel que soit le système d’exploitation ou la configuration de la machine.

    Cette approche me permet aussi de partager mes projets très facilement. Si quelqu’un veut tester ou contribuer, il n’a plus à installer une ribambelle de dépendances locales. L’environnement complet est encapsulé dans des conteneurs. C’est propre, isolé, et reproductible à l’identique.

    La maintenabilité, un vrai soulagement

    Un autre avantage que j’apprécie avec Docker, c’est la maintenabilité.
    Chaque service vit dans son propre conteneur, avec ses propres dépendances. Cela me permet de faire évoluer un composant sans risquer de casser les autres.

    Par exemple, si je dois mettre à jour la version de PostgreSQL ou de Node.js, il me suffit de modifier la configuration du conteneur concerné. Je rebuild l’image, je redémarre le tout, et c’est réglé.
    Pas de conflit de versions, pas de nettoyage interminable de paquets sur la machine hôte.

    De plus, le fait de tout définir dans du code (les fichiers Docker) rend la configuration beaucoup plus transparente et traçable. C’est du “configuration as code”, au même titre que le code source de l’application elle-même.

    Un gain de temps au quotidien

    Docker m’a aussi fait gagner un temps précieux sur des aspects souvent sous-estimés :

    • L’onboarding de nouveaux développeurs : plus besoin d’une demi-journée d’installation pour qu’ils puissent lancer le projet.
    • Les tests et la CI/CD : les pipelines utilisent exactement les mêmes images que moi, donc plus de surprise entre l’environnement local et celui du build.
    • Les déploiements : la transition entre développement et production devient beaucoup plus fluide.

    Ce confort au quotidien finit par devenir un réflexe. Je ne me demande plus “faut-il Dockeriser ce projet ?”, mais plutôt “comment le structurer proprement avec Docker dès le départ ?”.

    En conclusion : stabilité, simplicité, longévité

    Aujourd’hui, Docker fait partie intégrante de ma façon de développer.
    Il me permet d’avoir des projets plus stables, plus faciles à maintenir et surtout plus simples à partager.
    Je peux revenir sur un vieux dépôt des mois plus tard, lancer docker-compose up et retrouver un environnement fonctionnel en quelques secondes.

    Docker n’est pas parfait — il peut être lourd sur certaines machines, et la prise en main n’est pas toujours immédiate — mais une fois intégré dans le flux de travail, c’est difficile de s’en passer.

    Bref, pour moi, Docker n’est pas juste un outil pratique : c’est devenu une façon de penser mes projets.
    Portabilité, maintenabilité, sérénité.