# Algomax > Agence de développement web, mobile et IA basée à Strasbourg. Agents IA, applications SaaS, applications mobiles React Native, automatisations pour fondateurs non-techniques et PME. Ce fichier contient l'intégralité des articles de blog publiés, au format Markdown, destiné aux agents IA et moteurs de recherche conversationnels. Pour l'index court, voir /llms.txt. Chaque page publique expose aussi une variante Markdown directe via le suffixe .md. Site : https://algomax.fr Fondateur : Virgile Rietsch Contact : virgile@algomax.fr --- # Articles de blog ## Vibecoder une application mobile avec Claude Code : tutoriel 2026 (React Native + Expo) URL: https://algomax.fr/blog/vibecoder-application-mobile-claude-code Publié le : 2026-04-27 Description : Comment j'ai vibecodé une vraie app mobile en 2 h avec Claude Code, React Native et Expo. Tutoriel 2026 complet : de l'idée au build TestFlight, sans coder. ## Vibecoder une application mobile en 2 heures, c'est possible ? J'ai eu une greffe de foie. Tous les jours, je dois prendre cinq médicaments à des heures fixes, et je dois les renouveler à des dates différentes selon la taille des boîtes. Certaines contiennent 28 unités, d'autres 60, et tous les mois n'ont pas le même nombre de jours. Une feuille Excel ne suffit pas. Les apps existantes sont surchargées. Bref, le genre de besoin pour lequel une petite app mobile dédiée a un sens immédiat. Dans la vidéo, je construis cette application de zéro en moins de 2 heures, avec [Claude Code](https://www.anthropic.com/claude-code), [React Native](https://reactnative.dev) et [Expo](https://expo.dev), sans écrire une ligne de code à la main. C'est ce qu'on appelle aujourd'hui le vibecoding : vous écrivez le prompt, l'agent code, vous testez, vous corrigez. Cet article reprend le tutoriel étape par étape, avec les prompts exacts, le setup, le design system, et les bonnes pratiques que j'utilise au quotidien sur les applications mobiles livrées chez Algomax. J'ai aussi listé les pièges classiques à éviter en bas de l'article. > Couvert ici : scoping avec ChatGPT, setup Claude Code + Expo, fichier de contexte, skills.sh, design system itératif, notifications natives, OCR local Apple Vision, déploiement TestFlight. > > Pas couvert : publication finale sur l'Apple Store et le Play Store, qui demande des captures commerciales, un onboarding, une base de données et une licence Apple Developer. --- ## Comment vibecoder une application mobile avec Claude Code (résumé) Le workflow complet en 9 étapes : 1. Scoper le projet avec ChatGPT en 10 minutes (40 questions ciblées) 2. Préparer le setup : Expo, Cursor, Claude Code, simulateur iOS 3. Créer un fichier `app.md` qui sert de contexte permanent à l'agent 4. Installer les skills.sh de Vercel et créer un `claude.md` avec vos règles strictes 5. Brainstormer un design system avec 3 propositions, sauvegarder dans `design.md` 6. Itérer la UI en envoyant des captures d'écran à Claude Code 7. Activer les notifications natives via un EAS development build 8. Ajouter de l'IA locale (Apple Vision OCR) pour scanner une ordonnance 9. Déployer sur TestFlight pour tester sur un vrai iPhone Comptez 2 heures de dev pour un MVP fonctionnel, plusieurs semaines pour une app prête à publier sur les stores. --- ## Pourquoi vibecoder une application mobile en 2026 ? > **Le vibecoding, c'est quoi ?** La pratique de coder en déléguant l'écriture du code à un agent IA (Claude Code, Codex, Cursor) tout en gardant le contrôle des décisions techniques. Vous écrivez le prompt, l'agent code, vous testez, vous corrigez. La compétence passe de "savoir taper du code" à "savoir cadrer un projet et juger un résultat". Il y a deux ans, "coder une app mobile sans la coder" était une promesse marketing. En 2026, c'est devenu une réalité technique grâce à trois briques : 1. Les agents IA dans le terminal (Claude Code, [Codex](https://github.com/openai/codex), [Cursor](https://cursor.com)) qui lisent, écrivent et modifient du code avec un raisonnement cohérent sur des projets de plusieurs centaines de fichiers. 2. React Native + Expo, un framework JavaScript cross-platform qui produit une vraie application native iOS et Android à partir d'une seule base de code. Les modèles d'IA sont massivement entraînés dessus. 3. Les skills (skills.sh), un écosystème open-source de bonnes pratiques que les agents peuvent invoquer à la demande, sur la performance, la navigation, les animations, la gestion d'état. Résultat : un MVP fonctionnel en 2 heures pour un usage personnel ou un test interne. Pour vraiment développer une application mobile en production avec des utilisateurs payants, comptez plutôt plusieurs semaines pour soigner l'UX, les écrans App Store, l'onboarding, l'auth, le paiement et la base de données. Une limite à connaître avant de se lancer : le vibecoding mobile est plus contraint que le web. Apple et Google imposent des règles strictes sur les notifications, les permissions, l'accessibilité. Un humain compétent doit valider l'architecture avant la prod, sinon vous payez la dette technique très vite. J'en parle dans [Vibe coding, révolution ou piège pour les fondateurs](/blog/vibe-coding-revolution-ou-piege-pour-les-fondateurs). --- ## Étape 1 — Scoper le projet en 10 minutes avec ChatGPT La pire erreur quand on commence à vibecoder, c'est de demander tout de suite à Claude : "Code-moi une app qui fait X". L'agent va deviner, partir dans une direction qui ne vous correspond pas, et vous allez perdre 30 minutes à corriger. La bonne approche : faire interviewer [ChatGPT](https://chatgpt.com) avant d'écrire la moindre ligne. Voici le prompt que j'utilise : ``` J'aimerais créer une application mobile en React Native et Expo. [CONTEXTE PERSONNEL] Je prends des médicaments tous les jours suite à une greffe de foie. Les boîtes ont des tailles différentes (28, 60 unités). L'objectif est de me rappeler de prendre les médocs et de me prévenir quand je dois renouveler le stock. [CONSIGNE] Pose-moi des questions pour comprendre exactement le genre d'application que je souhaite créer. Une fois que tu auras tout le contexte, propose-moi un plan concret pour commencer le développement. [CONTRAINTES] - Pas de base de données. Hors ligne uniquement. - Aucun coût de fonctionnement. - 30 minutes à 1 heure de développement maximum. ``` ChatGPT va vous renvoyer 30 à 40 questions en plusieurs séries : utilisation, fonctionnalités, rappels, stock, technique, écrans. Répondez de façon concise. Comptez 10 minutes. > Pourquoi ça marche : les questions forcent ChatGPT à déterminer le scope avant de proposer un plan. Vous validez chaque détail au lieu de découvrir les choix de l'IA après coup. Le contexte généré sert ensuite de brief pour Claude Code. À la fin de l'interview, demandez le plan : architecture, fonctionnalités prioritaires, stack technique, écrans à construire. Copiez tout le contenu de la discussion. C'est votre brief, et il vous fera gagner des heures plus tard. --- ## Étape 2 — Préparer son setup : Expo, Cursor, Claude Code Avant de coder quoi que ce soit, installez les outils. | Outil | Rôle | Installation | |---|---|---| | Node.js | Runtime JavaScript | [nodejs.org](https://nodejs.org) (LTS) | | gh | CLI GitHub pour le versioning | `brew install gh` | | Cursor | Éditeur de code avec IA intégrée | [cursor.com](https://cursor.com) | | Claude Code | Agent IA dans le terminal | `npm install -g @anthropic-ai/claude-code` | | Expo | Framework cross-platform | Pas d'install globale, utilisez `npx create-expo-app` | Sur Mac, vous aurez aussi besoin de Xcode (gratuit sur le Mac App Store) pour le simulateur iOS. Sur Windows ou Linux, installez Android Studio pour le simulateur Android. Côté abonnements : Claude Code fonctionne avec n'importe quel plan Anthropic à partir de 20 $/mois. Pour ce tuto, j'utilise le plan à 200 $/mois avec Claude Opus 4.6, qui est aujourd'hui le meilleur modèle pour le code. Les plans plus bas marchent aussi avec Claude Sonnet, un peu moins puissant mais largement suffisant pour un MVP. Bootstrap du projet : ```bash # Créer un nouveau projet Expo npx create-expo-app dosetrack cd dosetrack # Lancer le simulateur iOS npm run ios # (ou Android) npm run android ``` À ce stade, l'application Expo par défaut tourne dans un simulateur. Ouvrez le projet dans Cursor (`cursor .`), faites un split simulateur + éditeur, et vous êtes prêt à vibecoder. --- ## Étape 3 — Donner du contexte à Claude (le fichier `app.md`) Pour qu'un vibecoding tienne dans la durée, l'agent a besoin d'un fichier de contexte stable qui ne bouge pas entre les conversations. Sans ça, vous re-expliquez le projet à chaque session, et l'agent perd la cohérence. Créez à la racine du projet un fichier `app.md` : ```markdown # DoseTrack — application de suivi de médicaments ## Objectif Application mobile React Native (Expo) qui rappelle à l'utilisateur de prendre ses médicaments et de renouveler les stocks. ## Architecture - Hors ligne, AsyncStorage uniquement - Plusieurs profils patients (futur) - TypeScript strict - Notifications locales (expo-notifications) ## Fonctionnalités [copiez ici tout le plan généré par ChatGPT] ## Écrans - Accueil : prochaines prises + alertes stock - Liste des médicaments + ajout - Historique des prises - Réglages ## Conventions - Architecture par domaine (services, features, types) - Zod pour les schemas - date-fns pour les dates ``` Lancez ensuite Claude Code en mode plan (`Maj+Shift` deux fois) : ``` Prends connaissance du fichier @app.md. Transforme-le en liste de tâches checkable que tu maintiendras à jour à chaque feature implémentée. Découpe en sprints : 1. Configuration (deps, structure) 2. Fondations (types, services) 3. UI (design system, composants) 4. Logique métier (rappels, renouvellement) 5. Notifications ``` Claude va explorer la base de code, identifier ce qui existe déjà (le boilerplate Expo), et réécrire `app.md` avec une liste de tâches structurée. Cette liste devient votre tableau Trello : à chaque feature livrée, l'agent coche la case et la prochaine instance Claude voit où en est le projet. > Astuce : si Claude se met à coder avant d'avoir réécrit `app.md`, arrêtez-le (`Esc`) et redemandez explicitement la mise à jour du fichier. Les agents sont "hypés" par le code et veulent sauter directement à l'implémentation. C'est un comportement classique. --- ## Étape 4 — Skills.sh et `claude.md` : la qualité du code généré C'est l'étape que 90 % des gens qui vibecodent ratent. Sans elle, votre code est syntaxiquement correct mais bourré d'anti-patterns. Pour faire du Claude Code mobile sérieux, c'est la fondation à poser tout de suite. ### Installer les skills (bonnes pratiques) [skills.sh](https://skills.sh) est un écosystème de bonnes pratiques pour agents IA, créé par [Vercel](https://vercel.com). Chaque skill est un fichier markdown qui décrit comment faire les choses correctement (performance, navigation, animations) sur un sujet précis. Pour ce projet, installez les skills React Native + Expo : ```bash # Skills Vercel React Native npx skills add vercel/vercel-react-native-skills # Skills Expo (UI native, fetching, upgrade) npx skills add expo/expo ``` Sélectionnez le scope projet et le mode symlink pour que tous vos agents (Claude Code, Cursor, Codex) lisent les mêmes règles. Les skills se retrouvent dans `agent/` à la racine du projet. J'ajoute par-dessus quatre skills officiels Anthropic et de la communauté qui changent la qualité du rendu : - `frontend-design` ([Anthropic](https://www.anthropic.com)) : composants soignés, espacements cohérents - `ui-ux-pro-max` : pousse l'agent vers un rendu pro plutôt que générique - `make-interface-feel-better` : micro-interactions, hover states, finitions - `simplify` : passe finale qui supprime la complexité inutile ### Créer un fichier `claude.md` avec vos règles strictes Claude Code lit automatiquement le fichier `claude.md` à la racine du projet. C'est l'endroit où vous fixez les règles non négociables : ```markdown # Règles Claude Code pour ce projet ## Obligations - Suis la progression dans @app.md (mets à jour après chaque feature) - Suis le design system dans @design.md - Lance toujours `npm run typecheck` et `npm run lint` après une modif - Mets à jour @app.md à la fin de chaque tâche ## Interdictions - Ne retire JAMAIS les accents des mots français (é, è, ê, à, ç...) - Ne dupliques pas les styles, factorise dans le design system - N'introduis pas de dépendance sans la justifier ## Mode plan (popularisé par Matt Pocock) - Plan extrêmement concis (sacrifie la grammaire pour la concision) - À la fin de chaque plan, liste les questions sans réponse ``` > Pourquoi le fichier `claude.md` : Claude n'utilise pas la convention `agents.md` standard. Pour rendre votre projet compatible avec Cursor, Codex et OpenCode, dupliquez le fichier en `agents.md` avec les mêmes règles. Entre chaque feature, fermez l'instance de Claude Code (`Ctrl+C`) et relancez-en une nouvelle. Le contexte fraîchement chargé évite la dégradation de qualité que tout agent connaît après 30+ messages. --- ## Étape 5 — Brainstormer un design system avec Claude Avant de coder une seule UI, fixez le design system. Sinon Claude va inventer des couleurs et des typos différentes sur chaque écran, et vous passerez la fin du projet à harmoniser. Le prompt : ``` Brainstormons ensemble le design system de cette application. Une fois les décisions prises, le design doit être cohérent sur l'ensemble de l'app. Fais-moi 3 propositions très différentes (style, couleur, typographie, ombres). Crée des composants visuels sur la page d'accueil pour que je voie le rendu de chaque proposition. Contexte : @app.md ``` Claude vous propose 3 directions visuelles distinctes (par exemple "Soft Clinical", "Bold Color", "Neo-Brutalist Medical") et les implémente en composants React Native que vous voyez immédiatement dans le simulateur. Vous choisissez celle qui vous parle. Descendez ensuite dans le détail : ``` Efface les 2 propositions non retenues. Maintenant propose-moi 4 palettes de couleurs primaires, 4 typographies (avec rendu visuel), et 3 niveaux d'ombre. ``` Une fois vos choix faits, forcez la sauvegarde dans un fichier dédié : ``` Sauvegarde notre design system complet dans un fichier @design.md, structuré ainsi : - Couleurs (light + dark mode) - Typographie (hiérarchie complète) - Ombres (subtle, medium, heavy) - Composants de base (Card, Button, Input) - Principes (cohérence, espacements, états) ``` Sans ce fichier, Claude réinvente le design à chaque conversation. Avec, vous avez une référence stable que tous vos agents partagent. --- ## Étape 6 — Itérer la UI avec des captures d'écran Un conseil contre-intuitif sur lequel je reviens souvent : pour faire du vibecoding mobile efficace, communiquez avec Claude par capture d'écran, pas par description textuelle. Quand vous voyez un titre tronqué ou un bouton mal positionné, faites une capture du simulateur, glissez-la dans Claude Code, et écrivez : ``` Voici l'écran d'ajout de médicament. [capture d'écran] Problèmes : 1. Le titre est tronqué en haut 2. Le menu catalogue n'est pas ergonomique → utilise un bottom sheet 3. Le formulaire n'est pas scrollable jusqu'en bas ``` Claude voit exactement ce que vous voyez. Il identifie la racine du problème (souvent un `lineHeight` foireux, un `KeyboardAvoidingView` mal configuré ou un `ScrollView` qui manque) et corrige sans tâtonner. Quelques patterns d'itération qui marchent bien : - Plusieurs instances Claude en parallèle. Une qui code, une qui review, une qui implémente la feature suivante. Vous gardez le contexte mental, l'IA exécute. - Demandez 3 propositions avant de choisir sur les décisions UX importantes (ex. "comment éditer une carte ?" : tap, swipe, icône stylo, menu long-press). - Utilisez les composants natifs : bottom sheet (`@gorhom/bottom-sheet`), switch, date picker. Plus performant qu'une vue custom. - Évitez le scroll infini sur les inputs numériques. Pour saisir 300 unités de stock, un input texte ou un stepper avec presets (10, 50, 100) bat un slider 1-par-1. > Anti-pattern : ne demandez jamais à Claude de "rendre l'écran plus joli". Soyez précis. "Le padding du bouton est trop grand, divise par 2", "le titre devrait être 24pt bold sur 2 lignes max". Ce niveau de précision sort de meilleurs résultats que des adjectifs. --- ## Étape 7 — Notifications natives sur React Native (EAS development build) C'est là que ça coince pour la plupart des gens. Les notifications locales sur iOS et Android ne fonctionnent pas dans Expo Go, l'application générique de test. Il vous faut un [development build](https://docs.expo.dev/develop/development-builds/create-a-build/), c'est-à-dire un vrai binaire de votre application compilé spécifiquement pour le développement. [EAS](https://docs.expo.dev/build/introduction/) (Expo Application Services) gère cette compilation dans le cloud d'Expo : ```bash # Installer le CLI EAS npm install -g eas-cli # Se connecter à son compte Expo eas login # Générer un development build pour iOS eas build --platform ios --profile development ``` Le build prend une dizaine de minutes côté serveur Expo. Le tier gratuit donne 15 builds iOS et 15 builds Android par mois ([source : tarifs Expo](https://expo.dev/pricing)), largement suffisant pour itérer sur un projet personnel. Une fois le build prêt, installez-le sur le simulateur (ou un device physique en TestFlight, voir étape 9), et relancez : ```bash npx expo start --dev-client ``` Votre application a maintenant accès aux APIs natives : notifications, caméra, capteurs, biométrie. Pour les rappels de médicaments, je m'appuie sur [`expo-notifications`](https://docs.expo.dev/versions/latest/sdk/notifications/) : ```typescript import * as Notifications from "expo-notifications"; await Notifications.scheduleNotificationAsync({ content: { title: "Advagraf 1 mg", body: "C'est l'heure de prendre votre médicament.", sound: "default", }, trigger: { type: Notifications.SchedulableTriggerInputTypes.CALENDAR, hour: 9, minute: 0, repeats: true, }, }); ``` Comptez environ 1 heure avec un agent IA bien briefé pour avoir cette feature complète. --- ## Étape 8 — IA locale sur iPhone : OCR avec Apple Vision Framework Cette feature est mon coup de cœur du projet. Scanner une ordonnance, gratuitement, sans aucune API cloud, en moins d'une seconde. Sur les iPhone récents, Apple expose l'API [Vision Framework](https://developer.apple.com/documentation/vision) : un OCR (reconnaissance de texte) qui tourne entièrement en local. Le texte ne sort jamais du téléphone, c'est gratuit, c'est rapide, et ça marche hors ligne. Le prompt à Claude : ``` Implémente une feature "scanner une ordonnance" : 1. L'utilisateur prend une photo (ou choisit dans la galerie) 2. On utilise l'API Apple Vision (locale) pour extraire le texte 3. On parse le texte pour détecter les médicaments du catalogue 4. On propose à l'utilisateur de les ajouter en un clic Si Apple Vision ne suffit pas, on basculera sur OpenAI plus tard. ``` Claude installe `@react-native-vision-camera/text-recognition` ou un wrapper équivalent, crée un écran de capture, et la pipeline de matching texte → médicaments. Limites de l'OCR local : - Reconnaissance de texte uniquement, pas de raisonnement. Pour passer de "4 mg" à "1 mg + 3 mg" (parce que 4 mg n'existe pas en pharmacie), il faut une couche de logique métier en plus. - Sur des ordonnances manuscrites, le taux d'erreur monte vite. - Pour de la production, basculez sur GPT-4 Vision ou Claude 4.6 Sonnet vision : payant, mais le raisonnement détecte beaucoup mieux les ambiguïtés. L'avantage du double système : vous proposez la feature gratuite par défaut (Apple Vision), avec un upgrade premium "scan IA avancé" (GPT-4) facturé à l'abonnement. Le genre de product-market fit incrémental qu'on recommande aux fondateurs sur [le développement d'une application mobile IA](/services/application-mobile-ia). --- ## Étape 9 — Publier sur TestFlight pour tester sur un vrai iPhone Le simulateur, c'est bien. Mais avant d'envoyer une beta à vos premiers utilisateurs, il faut tester sur un vrai device. Sur iOS, ça passe par [TestFlight](https://developer.apple.com/testflight/). Prérequis : - Un compte Apple Developer Program ([99 $/an](https://developer.apple.com/programs/), [source officielle Apple](https://developer.apple.com/programs/whats-included/)) - Un compte Expo (gratuit) - Un build production EAS Le déploiement se fait avec `eas submit` : ```bash # Lancer la pipeline de soumission iOS eas submit --platform ios # Le CLI vous pose les questions : # - Apple ID + mot de passe # - Bundle identifier (ex. com.algomax.dosetrack) # - Création des clés API push # - Réutilisation App Store Connect API key ``` Comptez environ 10 minutes pour le build et 10 minutes pour qu'Apple traite le binaire en arrière-plan. Vous recevez un email quand l'app est dispo sur TestFlight. Sur votre iPhone, ouvrez TestFlight, cliquez sur votre application, lancez-la. Vous testez maintenant l'application sur un device physique : les notifications partent pour de vrai, l'OCR Apple Vision tourne sur le matériel. La version expire au bout de 90 jours, le délai TestFlight standard, parfait pour itérer en beta. > Bon à savoir : la licence Apple Developer à 99 $/an n'est obligatoire que pour distribuer l'app (TestFlight + App Store). Pour tester en local sur votre device, vous pouvez signer l'app avec un compte Apple gratuit, mais la signature expire au bout de 7 jours et il faut re-signer manuellement. --- ## Les 5 pièges à éviter quand on vibecode du mobile Après avoir développé plus d'une dizaine d'applications mobiles avec mon agence Algomax, voici les erreurs récurrentes. ### 1. Laisser l'agent coder avant de scoper Symptôme : 30 minutes de code, et le résultat ne correspond pas du tout à ce que vous vouliez. Faites l'interview avec ChatGPT (étape 1) avant d'ouvrir Claude Code. ### 2. Ne pas reset le contexte entre les features Au bout de 30+ messages, n'importe quel agent commence à halluciner ou à oublier les règles. `Ctrl+C` puis nouvelle instance Claude Code à chaque feature majeure. Les fichiers `app.md`, `claude.md` et `design.md` rechargent le contexte essentiel automatiquement. ### 3. Ignorer le typecheck et le lint L'agent peut produire du code qui compile mais qui plante au runtime. Ajoutez `npm run typecheck` et `npm run lint` dans `claude.md` comme obligation après chaque modif. L'agent les exécute lui-même et corrige avant de vous rendre la main. ### 4. Décrire les bugs avec des mots au lieu de captures d'écran "Le bouton est moche" donne un résultat aléatoire. Privilégiez la capture d'écran avec une description précise (couleur exacte, padding, alignement). Visuel > textuel pour la UI. ### 5. Vouloir tout faire en une seule conversation L'agent est meilleur avec une feature à la fois. Un prompt = une intention claire. Si la feature est complexe, découpez en sous-tâches et créez plusieurs instances Claude Code en parallèle (notifications dans une, OCR dans l'autre, design dans une troisième). --- ## Conclusion : 2 heures pour un MVP, plusieurs semaines pour la production DoseTrack est sur mon iPhone. Elle me rappelle mes médicaments à 9 h et 21 h. Elle scanne mes ordonnances avec Apple Vision et m'alerte quand un stock baisse sous 25 %. Zéro dollar de dépensé, moins de 2 heures de travail. Maintenant, c'est un MVP personnel. Pour le transformer en application grand public publiable sur l'App Store, il faudrait ajouter : - Un onboarding et des écrans App Store soignés (captures, vidéo de démo, visuels commerciaux) - Une vraie base de données (Supabase ou Firebase) pour synchroniser entre devices - Une authentification (Sign in with Apple, Google) - Du paiement in-app pour les features premium (export, multi-profils) - Des analytics (Mixpanel, PostHog) pour comprendre comment les utilisateurs s'en servent - De la conformité (RGPD, CGU, mentions médicales) C'est typiquement le périmètre d'un MVP mobile sérieux. Si ce phasage vous parle, le retour d'expérience [Lancer un MVP mobile en 4 semaines](/blog/lancer-un-mvp-mobile-en-4-semaines) raconte comment on enchaîne ces étapes en produit livrable. Chez Algomax, on prend votre idée, on vibecode le squelette, on solidifie l'architecture, on intègre les services payants (auth, paiement, push), on publie sur les stores et on vous forme à itérer ensuite. Vous gardez le code. Si vous voulez chiffrer votre projet, on couvre ça en détail sur [la page prix d'une application mobile](/prix-application-mobile). [Voir le service développement d'application mobile](/services/application-mobile) Si vous préférez apprendre à le faire vous-même, [notre formation vibecoding](/formation-vibecoding) couvre exactement le workflow décrit dans cet article : prompts, fichiers de contexte, skills, patterns d'itération. Et si vous voulez en discuter de vive voix avant de vous lancer, [contactez-nous depuis la page contact](/contact) pour un appel découverte gratuit de 30 minutes. --- ## FAQ — vibecoder une application mobile ### Faut-il savoir coder pour vibecoder une application mobile ? Pas besoin de savoir taper du code à la main, mais il faut savoir lire le code généré et juger si c'est correct. Sans cette compétence, vous accumulez de la dette technique sans vous en apercevoir, et vous le payez au moment de la mise en production. Pour un MVP perso, vous pouvez avancer à l'aveugle. Pour une app destinée à des utilisateurs payants, prévoyez de vous faire accompagner par un dev qui valide l'architecture, ou apprenez les bases du JavaScript et de React Native en parallèle. ### Combien coûte une application mobile vibecodée ? Pour un MVP perso comme DoseTrack : 0 à 20 $/mois (un abonnement Anthropic suffit pour Claude Code, EAS Build est gratuit jusqu'à 15 builds iOS et 15 Android par mois). Pour publier sur l'App Store, comptez 99 $/an de licence Apple Developer. Pour une vraie app prête à monétiser, le coût devient celui du temps : 2 à 4 semaines de travail dev ou 8 à 12 k€ en prestation. Détail sur [la page prix d'une application mobile](/prix-application-mobile). ### Claude Code ou Cursor pour développer en React Native ? Sur mobile, je préfère Claude Code en mode terminal pour les raisons suivantes : meilleur sur les projets multi-fichiers, mode plan natif, support natif des skills.sh. Cursor reste excellent pour les tâches courtes en édition directe avec contexte visuel. La meilleure config en pratique : Claude Code pour piloter les features, Cursor ouvert sur le projet pour les corrections rapides à la souris. ### React Native ou Flutter pour le vibecoding ? React Native gagne pour le vibecoding en 2026, parce que les modèles d'IA sont massivement entraînés sur l'écosystème JavaScript et React. Flutter (Dart) est techniquement très solide, mais les agents IA produisent moins de code idiomatique sur Dart que sur React Native. Comparatif détaillé : [React Native ou Flutter, le guide pour non-techniques](/blog/react-native-ou-flutter-guide-pour-non-techniques). D'autres comparatifs techniques sont rassemblés sur [le hub comparatifs Algomax](/comparatifs). ### Quel modèle Claude utiliser pour coder une app mobile ? [Claude Opus 4.6](https://www.anthropic.com/claude/opus) reste le plus puissant en avril 2026 pour les projets complexes (architecture, refactor, multi-fichiers). Claude Sonnet 4.6 est largement suffisant pour les tâches d'implémentation classiques et coûte beaucoup moins cher en API. La règle pratique : Opus pour le mode plan et l'architecture, Sonnet pour exécuter les sprints. ### Peut-on vibecoder une application mobile pour Android ? Oui, exactement le même workflow fonctionne pour Android grâce à Expo + EAS Build. Côté simulateur, installez [Android Studio](https://developer.android.com/studio) au lieu de Xcode, et lancez `npm run android` au lieu de `npm run ios`. Pour la publication, le Play Store remplace l'App Store et la commande devient `eas submit --platform android`. Coût Google Play Developer : 25 $ une seule fois, contre 99 $/an chez Apple. ### Comment publier une application mobile sur l'App Store ? Trois étapes : (1) ouvrir un compte Apple Developer (99 $/an), (2) générer un build de production avec `eas build --platform ios --profile production`, (3) soumettre avec `eas submit --platform ios`. Apple effectue ensuite une revue manuelle qui prend de 24 h à 7 jours. Prévoyez aussi : captures d'écran (iPhone + iPad), texte App Store, politique de confidentialité, et tests TestFlight pour valider le bon fonctionnement avant la soumission. --- ## Sources vérifiées - skills.sh : écosystème de skills agents IA par Vercel ([skills.sh](https://skills.sh)) - EAS Build et tarifs ([expo.dev/pricing](https://expo.dev/pricing) : 15 builds iOS + 15 builds Android gratuits par mois) - Apple Developer Program ([developer.apple.com/programs](https://developer.apple.com/programs/) : 99 $/an) - Documentation EAS Build development build ([docs.expo.dev/develop/development-builds/create-a-build](https://docs.expo.dev/develop/development-builds/create-a-build/)) - Documentation Expo iOS submission ([docs.expo.dev/submit/ios](https://docs.expo.dev/submit/ios/)) - Vidéo originale ([youtu.be/qa5jMoJRQL8](https://youtu.be/qa5jMoJRQL8)) --- ## Pourquoi la dette technique coûte cher (et comment la détecter) URL: https://algomax.fr/blog/pourquoi-la-dette-technique-coute-cher-et-comment-la-detecter Publié le : 2026-03-25 Description : La dette technique ralentit votre développement et augmente vos coûts. Comment la détecter, la mesurer et la corriger avant qu'elle ne devienne critique. # Pourquoi la dette technique coûte cher (et comment la détecter) Votre équipe de développement met de plus en plus de temps à livrer. Les bugs se multiplient. Chaque nouvelle fonctionnalité prend le double du temps prévu. Et personne ne peut expliquer pourquoi. Il y a de grandes chances que le coupable soit la dette technique. ## C'est quoi la dette technique ? Imaginez une maison. Quand les fondations sont bien faites, vous pouvez ajouter des étages facilement. Quand elles sont bâclées, chaque étage supplémentaire fragilise l'ensemble. La dette technique, c'est ça : des raccourcis pris dans le code qui rendent chaque modification future plus difficile et plus risquée. Les raccourcis typiques : - Du code copié-collé au lieu d'être factorisé - Pas de tests automatisés (chaque modif peut casser l'app) - Une architecture qui mélange tout (logique métier, affichage, données) - Des dépendances obsolètes et jamais mises à jour - Du code que personne ne comprend (pas de documentation, noms de variables cryptiques) ## Pourquoi ça coûte cher ? ### Le ralentissement exponentiel Au début d'un projet, un développeur peut livrer une fonctionnalité par semaine. Avec de la dette technique accumulée, la même fonctionnalité prend 2 semaines, puis 3, puis un mois. Ce n'est pas que le développeur est mauvais. C'est que chaque modification nécessite de comprendre du code enchevêtré, de vérifier que rien d'autre ne casse, et de contourner des problèmes existants. ### Les bugs en cascade Sans tests et avec du code couplé, chaque modification peut créer des régressions. Vous corrigez un formulaire, la page de paiement casse. Vous ajoutez un champ, l'export CSV ne marche plus. Le temps passé à corriger des bugs n'est pas passé à développer des fonctionnalités. C'est du temps perdu. ### Le turnover des développeurs Les bons développeurs ne veulent pas travailler dans du code de mauvaise qualité. Ils quittent. Vous recrutez quelqu'un de nouveau qui met 2 mois à comprendre le code. Puis il quitte aussi. Le turnover coûte cher : recrutement, onboarding, perte de connaissance. Et le nouveau développeur ajoute encore plus de dette technique parce qu'il ne comprend pas l'architecture existante. ### L'impossibilité de pivoter Si votre code est rigide, changer de direction est extrêmement coûteux. Besoin de supporter un nouveau mode de paiement ? 3 mois au lieu de 2 semaines. Besoin de changer l'UI ? Tout refaire parce que les styles sont codés en dur partout. La dette technique tue l'agilité de votre entreprise. ## Comment détecter la dette technique ? Vous n'avez pas besoin d'être technique pour détecter ces signaux d'alerte : ### 1. Les estimations sont toujours dépassées Si une fonctionnalité estimée à "1 semaine" prend systématiquement 3 semaines, c'est souvent parce que le développeur découvre des problèmes cachés dans le code. ### 2. Les bugs augmentent au lieu de diminuer Un produit mature devrait avoir de moins en moins de bugs. Si c'est l'inverse, l'architecture ne protège pas contre les régressions. ### 3. Les développeurs refusent de toucher certaines parties du code "Ne touche pas à ce fichier" est un signal d'alarme. Un bon code est un code qu'on peut modifier en confiance. ### 4. L'onboarding des nouveaux développeurs est très long Si un nouveau développeur met plus de 2 semaines à être productif, le code n'est pas lisible. ### 5. Les performances se dégradent Pages qui mettent 5 secondes à charger, requêtes de base de données qui timeout, app mobile qui consomme la batterie. Ce sont souvent des symptômes de dette technique. ## Comment la corriger ? ### Étape 1 : Un audit technique Avant de corriger, il faut mesurer. Un [audit technique](/services/audit-technique) identifie les zones critiques et priorise les corrections. Le rapport d'audit vous dit : - Où est la dette technique - Quel est son niveau de criticité - Combien coûte la correction - Par quoi commencer ### Étape 2 : Corriger les fondations On ne corrige pas la dette technique en ajoutant du code. On la corrige en restructurant les fondations : - Ajouter des tests sur les parcours critiques - Séparer les responsabilités (logique métier, affichage, données) - Mettre à jour les dépendances - Documenter les parties complexes ### Étape 3 : Maintenir la qualité La dette technique revient si on ne met pas en place de garde-fous : - CI/CD avec tests automatisés (le code qui casse ne part pas en production) - Revue de code (un deuxième regard empêche les raccourcis) - Règles de qualité (linting, formatting, conventions) ## Combien ça coûte de corriger ? - **Audit technique** : 1 500€ - 3 000€ (3-5 jours) - **Corrections ciblées** : 5 000€ - 15 000€ (selon la taille du projet) - **Refonte architecturale** : 10 000€+ (quand les fondations sont irrécupérables) C'est un investissement, pas une dépense. Un code propre permet de livrer 2-3x plus vite, avec moins de bugs et moins de turnover. → [Service Audit Technique](/services/audit-technique) → [Service CTO Freelance](/services/cto-freelance) → [Service Vibe Coding Cleanup](/services/vibe-coding-cleanup) --- ## N8N vs Zapier vs Make : quel outil d'automatisation choisir ? URL: https://algomax.fr/blog/n8n-vs-zapier-vs-make-quel-outil-d-automatisation-choisir Publié le : 2026-03-23 Description : Comparatif N8N, Zapier et Make pour automatiser vos processus d'entreprise. Prix, fonctionnalités, IA, RGPD. Guide pratique pour décideurs. # N8N vs Zapier vs Make : quel outil d'automatisation choisir ? Vous passez des heures à copier-coller des données entre vos outils. À envoyer les mêmes emails manuellement. À synchroniser votre CRM avec votre outil de facturation. Il est temps d'automatiser. Mais quel outil choisir ? Ce guide compare les trois solutions les plus populaires : N8N, Zapier et Make (ex-Integromat). Pas de jargon, juste les critères qui comptent pour prendre une décision. ## Le résumé en 30 secondes - **Zapier** : le plus simple pour des automatisations basiques. Le plus cher quand le volume augmente. - **Make** : bon compromis entre simplicité et puissance. Moins cher que Zapier. - **N8N** : le plus puissant, le seul avec de l'IA avancée, le seul auto-hébergeable (RGPD). Nécessite un peu plus de setup. ## Zapier : le Plug & Play ### Points forts - **6 000+ intégrations** : quasiment tous les outils du marché sont connectés - **Interface très simple** : même un non-technique peut créer un "Zap" en 5 minutes - **Fiabilité** : ça marche. Zapier est solide et bien maintenu ### Points faibles - **Prix qui explose** : on paye par exécution. 100 tâches/mois = gratuit. 1 000 tâches = 20$/mois. 50 000 tâches = 600$/mois. À gros volume, la facture fait mal. - **Workflows linéaires** : les "Zaps" sont de A → B → C. Pas de boucles, peu de conditions. Pour les workflows complexes, c'est vite limité. - **Pas d'IA avancée** : quelques intégrations OpenAI basiques, mais pas d'agents, pas de RAG, pas de traitement de données intelligent. - **Pas auto-hébergeable** : vos données passent par les serveurs US de Zapier. RGPD ? À vos risques. ### Idéal pour Les petites entreprises avec des automatisations simples et un volume faible. "Quand je reçois un formulaire, envoyer un email et créer un contact CRM." ## Make (ex-Integromat) : le compromis ### Points forts - **1 500+ intégrations** : moins que Zapier, mais les principales y sont - **Interface visuelle** : un vrai builder de workflows visuels, plus flexible que Zapier - **Prix modéré** : paiement par opération, mais moins cher que Zapier à volume équivalent - **Workflows complexes** : boucles, conditions, routeurs. Plus puissant que Zapier ### Points faibles - **Toujours un coût par opération** : le prix augmente avec le volume - **Pas auto-hébergeable** : cloud uniquement, serveurs UE disponibles mais pas chez vous - **IA limitée** : quelques modules d'IA, mais pas d'agents ni de RAG natif - **Courbe d'apprentissage** : plus complexe que Zapier pour les débutants ### Idéal pour Les entreprises qui ont besoin de workflows plus complexes que Zapier permet, avec un budget raisonnable. ## N8N : le couteau suisse ### Points forts - **Open-source et auto-hébergeable** : vos données restent chez vous. RGPD by design. Vous contrôlez tout. - **Exécutions illimitées** : pas de coût par exécution. Vous payez uniquement l'hébergement (20-100€/mois). - **IA native** : c'est LA force de N8N. Agents IA avec outils, RAG pour interroger vos documents, classification, extraction. Des nœuds IA que Zapier et Make n'ont pas. - **Code custom** : nœuds JavaScript et Python pour les cas avancés. Le meilleur des deux mondes : no-code + code quand nécessaire. - **400+ intégrations** : moins que Zapier, mais les principales y sont. Et vous pouvez en créer des custom. ### Points faibles - **Installation nécessaire** : il faut installer N8N sur un serveur (ou utiliser le cloud N8N payant). Pas aussi "clic et c'est parti" que Zapier. - **Interface moins intuitive** : plus puissant = plus complexe. La prise en main demande un peu plus de temps. - **Moins d'intégrations natives** : 400 vs 6 000 pour Zapier. Pour les outils de niche, il faut parfois créer un connecteur custom. ### Idéal pour Les entreprises qui veulent intégrer de l'IA dans leurs automatisations, qui ont des volumes élevés, ou qui ont des contraintes RGPD fortes. ## Comparatif chiffré | Critère | Zapier | Make | N8N (auto-hébergé) | |---------|--------|------|-------------------| | 1 000 exécutions/mois | 20$/mois | 9$/mois | ~30€/mois (hosting) | | 10 000 exécutions/mois | 100$/mois | 29$/mois | ~30€/mois (hosting) | | 100 000 exécutions/mois | 600$/mois | 99$/mois | ~50€/mois (hosting) | | Agents IA | ❌ | ❌ | ✅ | | Auto-hébergement | ❌ | ❌ | ✅ | | RGPD garanti | ⚠️ | ⚠️ | ✅ | À partir de 10 000 exécutions/mois, N8N est le choix le plus économique. Et c'est le seul qui permet de créer des agents IA connectés à vos données. ## Notre recommandation Chez Algomax, on installe et configure N8N pour nos clients. Pas parce que c'est à la mode, mais parce que c'est le seul outil qui combine : 1. **IA avancée** : agents, RAG, classification — directement dans les workflows 2. **Contrôle total** : auto-hébergé, vos données restent chez vous 3. **Coût fixe** : pas de surprise sur la facture quand le volume augmente On peut aussi migrer vos Zaps Zapier vers N8N si vous êtes déjà utilisateur. → [Service Automatisation N8N](/services/automatisation-n8n) → [N8N vs Zapier : comparaison détaillée](/n8n-vs-zapier) --- ## React Native ou Flutter : guide pour non-techniques URL: https://algomax.fr/blog/react-native-ou-flutter-guide-pour-non-techniques Publié le : 2026-03-21 Description : React Native ou Flutter pour votre application mobile ? Comparaison simple pour fondateurs non-techniques : performances, coûts, recrutement, cas d'usage. # React Native ou Flutter : guide pour non-techniques Vous voulez créer une application mobile. Votre prestataire vous parle de React Native, un autre de Flutter. Vous ne savez pas ce que c'est, et encore moins lequel choisir. Ce guide est fait pour vous. Pas de jargon technique. Juste les critères qui comptent pour prendre une décision éclairée. ## La question de base : pourquoi choisir ? Les deux permettent de créer une application qui fonctionne sur iPhone ET Android avec une seule base de code. C'est-à-dire que vos développeurs écrivent le code une seule fois, et l'app fonctionne sur les deux plateformes. L'alternative, c'est le développement natif : deux équipes séparées, une pour iOS (Swift), une pour Android (Kotlin). Budget x2, délais x2, maintenance x2. Sauf cas très spécifique (jeux 3D, capteurs très pointus), ce n'est pas justifié. Donc le vrai choix est entre React Native et Flutter. ## React Native en 30 secondes - Créé par **Meta** (Facebook) en 2015 - Utilise **JavaScript** (le langage de programmation le plus utilisé au monde) - L'app utilise les composants natifs du téléphone (boutons, listes, navigation) - Utilisé par : Instagram, Discord, Shopify, Coinbase ## Flutter en 30 secondes - Créé par **Google** en 2018 - Utilise **Dart** (un langage créé par Google, moins répandu) - L'app dessine ses propres composants (moteur graphique propre) - Utilisé par : Google Pay, BMW, Alibaba, eBay Motors ## Les critères qui comptent pour vous ### 1. Recrutement de développeurs C'est souvent LE critère le plus important pour un fondateur. **React Native** utilise JavaScript. C'est le langage #1 mondial. Il y a des millions de développeurs JS, et la plupart peuvent apprendre React Native en quelques semaines. **Flutter** utilise Dart. Très peu de développeurs le connaissent. Le vivier est plus petit, les développeurs Flutter sont plus chers et plus difficiles à trouver. → **Avantage React Native** si vous comptez recruter en France. ### 2. Si vous avez déjà un site web Si votre startup a déjà un site ou une application web en React (très courant), **React Native** est le choix logique. Le même développeur peut travailler sur le web ET le mobile. Le code partage des logiques communes. Avec Flutter, aucune synergie avec votre codebase web existante. → **Avantage React Native** si vous avez un site en React. ### 3. Design sur mesure Si votre app nécessite un design très custom avec des animations complexes (app de jeu, app de dessin, interface non-standard), **Flutter** a un léger avantage. Son moteur graphique dessine tout pixel par pixel. React Native utilise les composants natifs, ce qui est un avantage pour les apps classiques (l'app "se comporte" comme une vraie app native), mais peut limiter les designs très exotiques. → **Avantage Flutter** pour les designs très custom. ### 4. Performance Les deux sont quasi-identiques en performance pour 95% des applications. Si votre app est un réseau social, un outil de productivité, un e-commerce, ou un SaaS : aucune différence perceptible. React Native a fait d'énormes progrès avec sa New Architecture (2024), qui élimine les anciens problèmes de performance. → **Match nul** pour les apps business classiques. ### 5. Coûts de développement Les coûts de développement initial sont similaires. La différence se fait sur le long terme : - **React Native** : plus facile de recruter, développeurs moins chers, écosystème NPM massif - **Flutter** : développeurs plus rares donc plus chers, écosystème en croissance mais plus petit → **Avantage React Native** sur le long terme. ## Notre recommandation Chez Algomax, on développe en React Native. Pas par dogmatisme, mais parce que pour la plupart des projets de nos clients (startups, PME, SaaS), c'est le choix le plus pragmatique : - JavaScript = facilité de recrutement - Écosystème NPM = bibliothèques pour tout - Composants natifs = l'app ressemble à une vraie app - Synergie web/mobile = un seul développeur pour les deux Flutter est un excellent choix aussi. Si votre prestataire est expérimenté en Flutter et que vous n'avez pas de codebase React existante, ça fonctionnera très bien. Le plus important n'est pas la technologie, c'est la qualité du développeur. → [Service Application Mobile](/services/application-mobile) → [React Native vs Flutter : comparaison détaillée](/react-native-vs-flutter) → [Combien coûte une application mobile en 2026 ?](/blog/combien-coute-une-application-mobile-en-2026) --- ## Vibe coding : révolution ou piège pour les fondateurs ? URL: https://algomax.fr/blog/vibe-coding-revolution-ou-piege-pour-les-fondateurs Publié le : 2026-03-19 Description : Le vibe coding permet de créer des apps sans coder. Mais est-ce vraiment une bonne idée pour votre startup ? Analyse honnête des avantages, des limites et des pièges à éviter. # Vibe coding : révolution ou piège pour les fondateurs ? Le vibe coding, c'est le mot à la mode dans la tech en 2025-2026. L'idée : vous décrivez ce que vous voulez à une IA (Lovable, Bolt, Cursor, Replit), et elle génère le code pour vous. Pas besoin de savoir coder. Pas besoin de développeur. Sauf que l'histoire est un peu plus nuancée que ça. ## C'est quoi le vibe coding, concrètement ? Le terme a été popularisé par Andrej Karpathy (co-fondateur d'OpenAI). L'idée : au lieu d'écrire du code ligne par ligne, vous décrivez le résultat souhaité en langage naturel, et l'IA génère le code. En pratique, les outils les plus utilisés sont : - **Lovable** : génère des applications web complètes à partir d'une description - **Bolt** : même principe, avec un focus sur les apps React - **Cursor** : IDE avec IA intégrée, pour des développeurs qui veulent aller plus vite - **V0** (Vercel) : génère des composants UI à partir de descriptions - **Replit** : environnement de développement en ligne avec IA Chacun a ses forces, mais ils partagent le même principe : vous décrivez, l'IA code. ## Ce qui est vraiment révolutionnaire ### La validation d'idée en quelques heures Avant le vibe coding, tester une idée d'app nécessitait soit de savoir coder (rare chez les fondateurs), soit de payer un développeur (5 000€+ pour un MVP minimal). Maintenant, un fondateur non-technique peut créer un prototype fonctionnel en quelques heures. Montrer le résultat à de vrais utilisateurs. Voir si l'idée tient la route. C'est un game-changer pour l'entrepreneuriat. ### La démocratisation de la tech Des milliers de personnes qui n'auraient jamais pu créer un produit tech peuvent maintenant le faire. C'est comme ce que WordPress a fait pour les sites web, mais en beaucoup plus puissant. ### Le coût d'entrée divisé par 100 Un prototype Lovable coûte 0 à 50€. Un prototype développé par un freelance coûte 2 000 à 10 000€. Pour valider une idée, le calcul est vite fait. ## Le piège : confondre prototype et produit Voici où ça se complique. La plupart des fondateurs qui utilisent le vibe coding font une erreur : ils pensent que le prototype EST le produit. ### Le code vibe-codé n'est pas fait pour la production Ce n'est pas une opinion, c'est un constat technique. Le code généré par Lovable, Bolt ou Cursor : - **N'a pas de tests** → chaque modification peut casser l'app - **N'a pas de gestion d'erreurs** → les crashs sont silencieux - **A une architecture fragile** → tout est couplé, impossible de modifier un écran sans casser un autre - **A une sécurité basique** → pas de validation serveur, tokens en clair - **N'est pas optimisé** → performances médiocres sur mobile C'est normal. Ces outils sont optimisés pour la vitesse de création, pas pour la qualité de production. Et c'est très bien comme ça — tant qu'on sait que c'est un prototype. ### Les stores refusent souvent les apps vibe-codées Apple et Google ont des critères stricts pour publier une app. Pas de crashs, pas de contenus qui chargent sans placeholder, performances correctes, respect des guidelines d'accessibilité. Le cas Vread est parlant : l'app a été [refusée 3 fois par Apple](/realisations/vread) avant qu'un développeur reprenne le code. Après la reprise technique, elle a été validée du premier coup. ### La dette technique s'accumule exponentiellement Avec du code vibe-codé, les premières modifications sont rapides. Mais la 10e modification prend 3x plus de temps que la 1re. La 20e prend 10x plus. C'est la dette technique en action. À un moment, vous passez plus de temps à corriger des régressions qu'à ajouter des fonctionnalités. C'est le signe que le code a atteint sa limite. ## La bonne stratégie pour les fondateurs Le vibe coding n'est pas un piège SI on l'utilise correctement. Voici la stratégie qui marche : ### Phase 1 : Valider avec le vibe coding (0-50€) Utilisez Lovable ou Bolt pour créer un prototype. Montrez-le à 10-20 utilisateurs potentiels. Récoltez des retours. Itérez sur le concept. À ce stade, la qualité du code n'a aucune importance. Ce qui compte, c'est de savoir si des gens veulent votre produit. ### Phase 2 : Reprendre avec un développeur (5 000-15 000€) Si l'idée est validée, faites reprendre le code par un développeur senior. Il gardera ce qui marche (souvent 40-60% du code), corrigera ce qui ne va pas, et ajoutera les fondamentaux (tests, sécurité, architecture). C'est le [vibe coding cleanup](/services/vibe-coding-cleanup) : on ne repart pas de zéro, on transforme le prototype en produit. ### Phase 3 : Itérer en production Avec un code propre, vous pouvez ajouter des fonctionnalités rapidement et en confiance. Chaque sprint produit du nouveau, pas des corrections de bugs. ## Combien ça coûte au total ? - Prototype vibe-codé : 0-50€ - Reprise par un développeur : 5 000-15 000€ - Total : 5 000-15 000€ Compare avec un développement from scratch : - MVP complet : 10 000-25 000€ Le vibe coding + reprise est souvent **moins cher** que de tout faire développer de zéro. Et vous avez la validation utilisateur en bonus. ## Conclusion Le vibe coding est une révolution pour la phase de validation. C'est un piège si vous pensez que le prototype peut aller en production tel quel. La bonne approche : utilisez le vibe coding pour valider, puis faites appel à un développeur pour aller en production. → [Service Vibe Coding Cleanup](/services/vibe-coding-cleanup) → [Lovable vs Développeur : quand faire le switch ?](/lovable-vs-developpeur) --- ## CTO externe : c'est quoi et c'est pour qui ? URL: https://algomax.fr/blog/cto-externe-c-est-quoi-et-c-est-pour-qui Publié le : 2026-03-17 Description : Un CTO freelance, c'est un directeur technique sans le CDI. Quand en recruter un, combien ça coûte, et ce que ça change pour votre startup. Retour d'expérience GoodCollect. # CTO externe : c'est quoi et c'est pour qui ? Vous lancez une startup tech. Vous avez l'idée, les premiers clients, peut-être même une levée en vue. Mais vous n'êtes pas technique. Qui va choisir la stack ? Recruter les développeurs ? S'assurer que le code tiendra quand vous aurez 1 000 utilisateurs ? Un CTO salarié coûte 80 000 à 120 000€ par an (+ charges). En early-stage, c'est rarement viable. Mais sans direction technique, vous prenez des décisions à l'aveugle. C'est là qu'un CTO externe entre en jeu. ## C'est quoi un CTO externe ? Un CTO externe (ou CTO freelance) est un directeur technique qui intervient à temps partiel dans votre entreprise. Il a le même rôle qu'un CTO salarié — architecture, recrutement, roadmap technique — mais sans le CDI et le salaire fixe. Concrètement, il travaille 2-3 jours par semaine sur votre projet. Il prend les décisions techniques, manage l'équipe (s'il y en a une), et s'assure que la tech sert le business. ### Ce n'est PAS un développeur freelance La confusion est fréquente. Un développeur freelance exécute des tâches techniques : "développe cette fonctionnalité", "corrige ce bug". Un CTO prend du recul et se demande : "est-ce qu'on devrait même développer cette fonctionnalité ?" Un CTO : - Choisit la stack et l'architecture - Recrute et manage les développeurs - Priorise la roadmap technique - Anticipe les problèmes de scaling - Aligne la tech avec le business ## Mon expérience de CTO chez GoodCollect Pendant 2 ans, j'ai été CTO de [GoodCollect](/realisations/goodcollect), une startup SaaS B2B dans la gestion des déchets professionnels. ### Ce que j'ai trouvé en arrivant Une startup avec de la traction mais une base technique fragile. Pas de paiements sécurisés, support client 100% manuel, dette technique accumulée. Les revenus n'étaient pas récurrents et la plateforme ne supportait pas bien la charge. ### Ce que j'ai fait - **Architecture** : refonte de la base technique pour la stabilité et les performances - **Paiements** : intégration Stripe avec abonnements récurrents (revenus sécurisés et prévisibles) - **Automatisation** : bot WhatsApp pour le support client (support 24/7 sans embauche) - **Qualité** : CI/CD, tests e2e, monitoring (le code qui part en production est testé) - **Management** : priorisation de la roadmap, coordination avec l'équipe ### Le résultat Un SaaS rentable avec des revenus récurrents, un support automatisé, et une base technique solide. La plateforme pouvait scaler sans que quelqu'un soit de garde la nuit. ## Quand une startup a-t-elle besoin d'un CTO ? ### Dès le pré-seed / seed C'est le moment le plus critique. Les décisions techniques prises au début sont les plus difficiles (et les plus chères) à changer après. Un CTO freelance à ce stade permet de : - Choisir la bonne stack (celle qu'on pourra recruter facilement) - Éviter la dette technique dès le jour 1 - Structurer l'architecture pour pouvoir scaler - Construire un MVP rapidement ET proprement ### Avant une levée de fonds Les investisseurs font de la tech due diligence. Ils veulent savoir si votre code est maintenable, si l'architecture tient la route, et si la dette technique est gérable. Un CTO freelance peut préparer cette étape. ### Quand les bugs s'accumulent Si chaque sprint produit plus de bugs qu'il n'en corrige, c'est que l'architecture a un problème. Un CTO externe peut faire un audit, identifier les causes racines, et mettre en place un plan de remédiation. ## Combien ça coûte ? Soyons transparents : - **Audit ponctuel** : 1 500€ - 3 000€ (1 semaine). Évaluation de votre code, architecture et dette technique. - **CTO temps partiel** (2-3 jours/semaine) : 3 000€ - 6 000€/mois. Le format le plus courant. - **CTO full-time temporaire** (lancement, transition) : 8 000€ - 12 000€/mois. Compare avec un CTO salarié : - Salaire + charges : 100 000€ - 180 000€/an - CTO freelance temps partiel : 36 000€ - 72 000€/an C'est 3-5x moins cher. Et vous pouvez ajuster le volume selon les phases du projet. ## CTO freelance vs CTO salarié : quand passer en CDI ? Le CTO freelance est idéal pour les phases de lancement et de structuration. Quand votre startup atteint les critères suivants, il est temps de recruter un CTO interne : - **Équipe tech > 5 personnes** : le management au quotidien justifie un temps plein - **Revenue > 500K€ ARR** : vous pouvez vous permettre le salaire - **Produit stabilisé** : les choix structurants sont faits Un bon CTO freelance prépare cette transition : il rédige la fiche de poste, participe au recrutement, et fait le handover. ## Comment choisir un CTO freelance ? Cherchez quelqu'un qui a : 1. **Une expérience réelle de CTO**, pas juste du développement. Demandez-lui s'il a déjà recruté des devs, managé une équipe, pris des décisions d'architecture en situation de stress. 2. **De l'expérience en production**. Tout le monde peut coder un projet perso. Gérer un SaaS avec de vrais utilisateurs et de vrais revenus, c'est autre chose. 3. **La capacité de dire non**. Un bon CTO refuse des fonctionnalités. Il dit "pas maintenant" quand c'est nécessaire. Si votre CTO dit oui à tout, ce n'est pas un CTO, c'est un exécutant. → [Service CTO Freelance](/services/cto-freelance) → [Voir le cas GoodCollect](/realisations/goodcollect) --- ## Reprise de projet Lovable : ce que personne ne vous dit URL: https://algomax.fr/blog/reprise-de-projet-lovable-ce-que-personne-ne-vous-dit Publié le : 2026-03-15 Description : Votre prototype Lovable plante ? Bugs en production, refus Apple, régressions à chaque modification. Retour d'expérience concret sur la reprise d'un projet vibe-codé. # Reprise de projet Lovable : ce que personne ne vous dit Vous avez créé votre prototype avec Lovable en quelques heures. L'app avait l'air bien. Vous l'avez montrée à vos premiers utilisateurs, ils ont aimé le concept. Vous vous êtes dit : "Il suffit de corriger quelques bugs et on est bons." Sauf que trois mois plus tard, vous êtes toujours en train de corriger des bugs. Et chaque correction en crée deux nouveaux. Ce n'est pas votre faute. C'est la nature même du vibe coding. ## Ce que Lovable fait très bien Soyons honnêtes : Lovable est un outil remarquable. En quelques heures, vous obtenez un prototype fonctionnel avec une UI propre. Pour valider une idée auprès de vrais utilisateurs, c'est imbattable. Le problème, ce n'est pas Lovable. C'est de croire que le prototype peut aller en production tel quel. ## Ce que le code Lovable a vraiment sous le capot J'ai repris plusieurs projets Lovable. Voici ce que je trouve systématiquement : ### Pas de gestion d'erreurs Quand tout va bien, l'app fonctionne. Mais dès qu'une API renvoie une erreur, qu'un utilisateur fait quelque chose d'imprévu, ou que la connexion est lente... crash silencieux. L'utilisateur voit un écran blanc ou des données incohérentes. ### Pas de tests Zéro test automatisé. Ça veut dire que chaque modification peut casser n'importe quelle autre partie de l'app. Et vous ne le saurez qu'en production, quand un utilisateur vous envoie un screenshot de bug. ### Architecture inexistante Des composants géants de 500 lignes qui mélangent la logique métier, l'affichage et les appels API. Pas de séparation des responsabilités. Résultat : impossible de modifier une fonctionnalité sans toucher à tout le reste. ### State management chaotique Les données se perdent entre les écrans. Un utilisateur remplit un formulaire, navigue, revient : tout a disparu. Ou pire : les données d'un utilisateur s'affichent chez un autre. ### Sécurité basique Pas de validation côté serveur, pas de rate limiting, tokens stockés en clair. Pour un prototype, ça passe. Pour une app en production avec des données utilisateur, c'est un risque juridique. ## Le cas Vread : 3 refus Apple, puis App Store Tanguy, fondateur de [Vread](https://www.vread.fr/), avait exactement ce problème. Son app de suivi de lecture, créée avec Lovable, fonctionnait visuellement mais était instable. Apple a refusé l'app 3 fois : crashs au lancement, non-respect des guidelines, problèmes de performance. ### Ce qu'on a fait **Audit (3 jours)** : On a analysé tout le code. Identifié 47 bugs critiques, 12 failles de sécurité, et une architecture qui rendait toute correction risquée. **Reprise technique (3 semaines)** : Refactoring de l'architecture React Native, correction de la gestion d'état, ajout d'error boundaries et de tests sur les parcours critiques. **Refonte UX/UI (1 semaine)** : Harmonisation du design, système de composants cohérent. **Résultat** : App validée par Apple du premier coup après la reprise. Code maintenable, testable, prêt pour les futures évolutions. → [Lire l'étude de cas complète](/realisations/vread) ## Les 5 signaux que votre projet Lovable a besoin d'une reprise 1. **Chaque modification crée de nouveaux bugs.** Vous corrigez un formulaire, le panier casse. Vous ajoutez un écran, la navigation plante. C'est le signe d'une architecture couplée. 2. **Apple ou Google refusent votre app.** Les stores ont des critères stricts : pas de crashs, pas de contenus chargés sans placeholder, performances correctes. Le code Lovable ne passe souvent pas ces filtres. 3. **Les utilisateurs signalent des bugs que vous ne pouvez pas reproduire.** Sans logging et sans tests, vous êtes aveugle. Les bugs intermittents sont les pires. 4. **Vous avez peur de toucher au code.** Quand modifier une ligne vous stresse, c'est que l'architecture ne vous protège pas. Un bon code est un code qu'on peut modifier en confiance. 5. **Le temps de développement augmente au lieu de diminuer.** Avec un code bien structuré, les fonctionnalités s'ajoutent de plus en plus vite. Avec de la dette technique, c'est l'inverse. ## Combien ça coûte ? Soyons transparents : - **Audit technique** : 1 500€ - 3 000€ (3-5 jours). Vous savez exactement ce qui ne va pas et combien ça coûtera à corriger. - **Reprise & stabilisation** : 5 000€ - 15 000€ (2-8 semaines). On garde ce qui marche, on corrige ce qui casse. - **Refonte complète** : à partir de 10 000€ (2-4 mois). Quand le code est irrécupérable. Dans 70% des cas, on n'a pas besoin de tout refaire. On garde la base et on corrige les parties critiques. ## La bonne stratégie : prototype + développeur Lovable (ou Bolt, Cursor, V0) n'est pas le problème. Le problème, c'est de s'arrêter au prototype. La bonne stratégie : 1. **Valider l'idée** avec Lovable (budget : 0-50€) 2. **Faire reprendre le code** par un développeur senior (budget : 5 000-15 000€) 3. **Itérer en production** avec un code maintenable (budget : au fur et à mesure) C'est moins cher que de tout faire développer de zéro. Et beaucoup moins cher que de perdre 6 mois à essayer de patcher du code vibe-codé. → [Voir le service Vibe Coding Cleanup](/services/vibe-coding-cleanup) → [Lovable vs Développeur : quand faire le switch ?](/lovable-vs-developpeur) --- ## Automatisation : no-code, low-code ou sur mesure ? URL: https://algomax.fr/blog/automatisation-no-code-low-code-ou-sur-mesure Publié le : 2026-02-27 Description : Quelle approche d'automatisation choisir pour votre entreprise ? Comparaison objective entre les solutions no-code (Zapier, Make), low-code (N8N) et le développement sur mesure. # Automatisation : no-code, low-code ou sur mesure ? Votre assistante passe 3 heures par jour à recopier des données d'un outil à l'autre. Votre comptable exporte des CSV (des fichiers de données type tableur) pour les réimporter ailleurs. Votre commercial copie-colle des informations entre son CRM et son outil d'emailing. Ces tâches sont répétitives, sans valeur ajoutée, et coûtent une fortune en temps salarié. Vous savez qu'il faut automatiser. Mais comment ? Trois approches s'offrent à vous. Le no-code, avec des outils comme Zapier ou Make. Le low-code, avec des plateformes comme N8N. Et le développement sur mesure, avec une équipe qui construit exactement ce dont vous avez besoin. Chaque approche a ses forces et ses limites. Cet article vous aide à choisir celle qui correspond à votre situation, votre budget et vos ambitions. ## Ce que "automatiser" veut dire concrètement Avant de comparer les outils, clarifions le sujet. Automatiser un processus, c'est faire en sorte qu'une tâche se déclenche et s'exécute sans intervention humaine. Quelques exemples du quotidien : - Un formulaire est rempli sur votre site web. Automatiquement, un contact est créé dans votre CRM, un email de bienvenue est envoyé, et votre commercial reçoit une notification Slack. - Une facture arrive par email. Elle est automatiquement lue, les montants sont extraits, et une écriture comptable est pré-remplie dans votre logiciel. - Un client laisse un avis négatif sur Google. Une alerte est envoyée au responsable, un ticket de suivi est créé, et un email d'excuse personnalisé est envoyé dans l'heure. L'automatisation connecte vos outils entre eux et élimine les étapes manuelles. Le résultat : moins d'erreurs, plus de rapidité, et vos équipes libérées pour des tâches à valeur ajoutée. ## Les 3 approches expliquées ### No-code : Zapier, Make (ex-Integromat) Le no-code, c'est l'automatisation par glisser-déposer. Vous sélectionnez un déclencheur ("quand un email arrive"), vous choisissez une action ("créer un contact dans le CRM"), et le tour est joué. Aucune ligne de code. **Comment ça marche :** ces plateformes proposent des milliers de connecteurs pré-construits. Gmail, Slack, HubSpot, Notion, Google Sheets, Stripe : la plupart des outils courants sont disponibles. Vous assemblez des blocs comme des Lego. **Les points forts :** - Mise en place en quelques heures, parfois quelques minutes - Aucune compétence technique requise - Coût d'entrée bas : Zapier à partir de 20 euros/mois, Make à partir de 10 euros/mois - Idéal pour les automatisations simples et standard **Les limites :** - **Coûts qui explosent avec le volume.** Zapier facture au nombre de tâches. 1 000 tâches par mois, ça va. 50 000 tâches, vous payez 500 à 800 euros par mois. Pour un processus à haut volume, ça devient vite plus cher que du sur mesure. - **Logique limitée.** Si votre automatisation a besoin de conditions complexes, de boucles, de transformations de données avancées, vous atteignez vite les limites. C'est comme essayer de construire une maison avec des Lego Duplo. - **Dépendance au fournisseur.** Si Zapier change ses tarifs, supprime un connecteur, ou tombe en panne, vos automatisations s'arrêtent. Vous n'avez aucun contrôle. - **Pas d'accès à vos données internes.** Ces outils connectent des services en ligne. Si vos données sont dans une base de données interne ou un système propriétaire, il n'y a pas de connecteur. ### Low-code : N8N, Activepieces Le low-code est un intermédiaire. L'interface visuelle est là, comme en no-code. Mais vous pouvez aussi écrire du code quand c'est nécessaire. Et surtout, vous hébergez l'outil chez vous. **Comment ça marche :** N8N, par exemple, est un logiciel open source (gratuit et modifiable librement) que vous installez sur votre propre serveur. L'interface est similaire à Zapier : des blocs, des connexions, des déclencheurs. Mais chaque bloc peut contenir du code personnalisé si nécessaire. **Les points forts :** - **Coût fixe et prévisible.** N8N en auto-hébergé coûte le prix de votre serveur (20 à 100 euros/mois). Pas de facturation à la tâche. 10 tâches ou 10 millions, même prix. - **Flexibilité.** Vous combinez des blocs visuels et du code. Les automatisations complexes deviennent possibles. - **Vos données restent chez vous.** Tout tourne sur votre infrastructure. Aucune donnée ne transite par un service tiers. Idéal pour les données sensibles et la conformité RGPD. - **Open source.** Pas de dépendance à un fournisseur. Si N8N disparaît demain, votre installation continue de fonctionner. **Les limites :** - **Besoin de compétences techniques.** L'installation, la configuration et la maintenance demandent quelqu'un qui s'y connaît. Ce n'est pas insurmontable, mais ce n'est pas du "cliquez et ça marche". - **Moins de connecteurs natifs.** N8N a des centaines d'intégrations, mais moins que Zapier qui en a des milliers. Pour un outil de niche, vous devrez peut-être créer le connecteur vous-même. - **Maintenance à votre charge.** Mises à jour, sauvegardes, monitoring : c'est vous (ou votre prestataire) qui gérez. Chez Algomax, nous recommandons souvent N8N comme base d'automatisation. C'est le meilleur rapport puissance/coût pour les PME. Consultez notre offre d'[automatisation avec N8N](/services/automatisation-n8n) pour en savoir plus. ### Sur mesure : développement spécifique Le sur mesure, c'est un développeur (ou une équipe) qui construit exactement l'automatisation dont vous avez besoin, sans passer par une plateforme intermédiaire. **Comment ça marche :** on écrit du code qui connecte vos systèmes, traite vos données, et exécute vos processus. Pas de contraintes de plateforme. Pas de limites de connecteurs. Si c'est techniquement possible, c'est faisable. **Les points forts :** - **Aucune limite fonctionnelle.** Logique complexe, traitement de données massif, intégration avec des systèmes propriétaires : tout est possible. - **Performance optimale.** Le code est écrit pour votre cas précis. Pas de couche intermédiaire qui ralentit. - **Intégration d'IA.** Le sur mesure permet d'intégrer des modèles d'intelligence artificielle dans vos automatisations : lecture de documents, classification, prise de décision. Les plateformes no-code ne le permettent que de façon très limitée. - **Propriété totale.** Le code vous appartient. Aucune dépendance à un service tiers. **Les limites :** - **Coût initial élevé.** Comptez 3 000 à 15 000 euros par automatisation, selon la complexité. C'est significativement plus cher qu'un abonnement Zapier, du moins au départ. - **Délai de mise en place.** 2 à 8 semaines selon la complexité, contre quelques heures en no-code. - **Besoin de maintenance.** Le code doit être maintenu, mis à jour quand les API des services connectés changent. Pour les automatisations qui intègrent de l'intelligence artificielle, consultez notre page sur les [agents IA sur mesure](/services/agent-ia-sur-mesure). ## Comparaison directe | Critère | No-code (Zapier, Make) | Low-code (N8N) | Sur mesure | |---|---|---|---| | **Mise en place** | Quelques heures | Quelques jours | 2-8 semaines | | **Coût mensuel (faible volume)** | 20-50 euros | 20-100 euros (serveur) | 0 euros (après dev) | | **Coût mensuel (fort volume)** | 500-1 500 euros | 20-100 euros (serveur) | 0 euros (après dev) | | **Coût initial** | Quasi nul | Faible (config) | 3 000-15 000 euros | | **Complexité possible** | Simple | Moyenne à élevée | Illimitée | | **Compétences requises** | Aucune | Basiques | Développeur | | **Données sensibles** | Non recommandé | Oui (auto-hébergé) | Oui | | **Intégration IA** | Très limitée | Possible | Complète | | **Maintenance** | Par le fournisseur | Par vous/prestataire | Par vous/prestataire | ## Quand utiliser chaque approche ### Choisissez le no-code si : - Vos automatisations sont simples : un déclencheur, une ou deux actions - Le volume est faible : moins de 1 000 tâches par mois - Vous n'avez aucune ressource technique - Vous avez besoin d'un résultat immédiat - Les données ne sont pas sensibles Exemples typiques : envoyer un email de bienvenue après une inscription, notifier un canal Slack quand un formulaire est rempli, synchroniser des contacts entre deux outils. ### Choisissez le low-code (N8N) si : - Vos automatisations ont une logique métier spécifique - Le volume est élevé ou imprévisible - Vous traitez des données sensibles (données clients, données financières) - Vous voulez un coût prévisible, indépendant du volume - Vous avez un prestataire technique ou une personne technique en interne Exemples typiques : traitement automatisé de commandes avec vérification de stock, synchronisation bidirectionnelle entre un CRM et un ERP, chaîne de traitement automatisée de candidatures RH. ### Choisissez le sur mesure si : - L'automatisation est au coeur de votre proposition de valeur - Vous avez besoin d'intégrer de l'intelligence artificielle - Vos systèmes sont propriétaires ou non standards - La performance et la fiabilité sont critiques - Le volume justifie l'investissement initial Exemples typiques : agent IA qui traite les emails entrants et crée des tickets qualifiés, système de pricing dynamique basé sur l'analyse de marché, chaîne de traitement documentaire avec OCR (reconnaissance automatique de texte dans les images) et extraction de données. ## L'approche hybride : le meilleur des deux mondes Dans la pratique, la plupart des entreprises n'utilisent pas une seule approche. Elles combinent. Voici un schéma que nous mettons en place régulièrement chez nos clients : ### Couche 1 : No-code pour le simple Les automatisations basiques qui connectent des outils standard. Notifications, synchronisations simples, envoi d'emails transactionnels. Zapier ou Make fait le travail en quelques minutes. ### Couche 2 : N8N pour le coeur de métier Les processus métier spécifiques, avec de la logique, des conditions, du traitement de données. N8N, auto-hébergé, géré par votre prestataire technique. Coût fixe, flexibilité maximale. ### Couche 3 : Sur mesure pour l'IA et le critique Les automatisations qui intègrent de l'intelligence artificielle ou qui sont critiques pour votre activité. Développées sur mesure, testées, monitorées. Cette approche en couches permet de démarrer rapidement avec le no-code, de migrer progressivement vers N8N quand les coûts ou les limites deviennent un problème, et de développer sur mesure uniquement ce qui le justifie. ## Combien ça coûte au total ? Voici un budget type pour une PME de 20 à 50 personnes qui automatise ses processus principaux : ### Scénario 1 : Tout en no-code - 10 automatisations simples sur Zapier ou Make - Coût mensuel : 100 à 300 euros - Coût annuel : 1 200 à 3 600 euros - Limitations : volume plafonné, logique simple uniquement ### Scénario 2 : N8N auto-hébergé - 20 automatisations de complexité variable sur N8N - Coût de mise en place : 2 000 à 5 000 euros (installation, configuration, formation) - Coût mensuel : 50 à 150 euros (hébergement + maintenance) - Coût annuel : 2 600 à 6 800 euros (première année), 600 à 1 800 euros (années suivantes) - Pas de limite de volume ### Scénario 3 : Hybride (recommandé) - 5 automatisations simples en no-code : 50 euros/mois - 10 automatisations métier sur N8N : 100 euros/mois (hébergement) - 2 automatisations IA sur mesure : 10 000 euros (développement initial) - Coût première année : environ 12 000 euros - Coût années suivantes : environ 2 000 euros/an - Aucune limitation fonctionnelle Le scénario hybride coûte plus cher la première année, mais devient le moins cher dès la deuxième année, tout en offrant la plus grande flexibilité. ## Par où commencer ? Si vous ne savez pas quelle approche choisir, voici un plan d'action en trois étapes. ### Étape 1 : Lister vos processus répétitifs Demandez à chaque membre de votre équipe : "Quelle tâche fais-tu chaque jour que tu aimerais ne plus faire ?" Vous obtiendrez une liste de 10 à 20 processus automatisables en moins d'une heure. ### Étape 2 : Classer par impact et complexité Pour chaque processus, estimez : - **Le temps gagné par semaine** : 30 minutes ? 2 heures ? 1 jour ? - **La complexité** : simple (un déclencheur, une action) ? moyenne (conditions, boucles) ? complexe (IA, systèmes propriétaires) ? Commencez par les processus à fort impact et faible complexité. Les "quick wins". ### Étape 3 : Commencer avec le bon outil - Les quick wins simples ? Mettez-les sur Zapier ou Make en une après-midi. - Les processus métier importants ? Planifiez une installation N8N avec un prestataire. - Les automatisations stratégiques avec IA ? Contactez-nous pour un audit. ## Passez à l'action L'automatisation n'est pas un projet ponctuel. C'est une démarche continue qui libère progressivement votre équipe des tâches répétitives. Chez Algomax, nous accompagnons les entreprises dans cette démarche. De la mise en place d'[automatisations avec N8N](/services/automatisation-n8n) au développement d'[agents IA sur mesure](/services/agent-ia-sur-mesure) pour les processus les plus complexes. Prenez rendez-vous pour un audit gratuit de vos processus. En 30 minutes, on identifie les 3 automatisations les plus impactantes pour votre entreprise et on vous recommande l'approche adaptée. Sans jargon. Sans engagement. --- ## Lancer un MVP mobile en 4 semaines URL: https://algomax.fr/blog/lancer-un-mvp-mobile-en-4-semaines Publié le : 2026-02-26 Description : Les étapes concrètes pour passer de l'idée à une application mobile fonctionnelle en un mois. Priorisation, développement, tests et lancement. # Lancer un MVP mobile en 4 semaines Vous avez une idée d'application mobile. Vous en parlez depuis des mois. Vous avez rempli des pages de notes, esquissé des écrans sur un carnet, peut-être même fait un tableau Excel avec toutes les fonctionnalités imaginables. Et vous n'avez toujours rien de concret entre les mains. Le problème n'est pas l'idée. Le problème, c'est l'approche. Trop de fondateurs veulent construire l'application parfaite du premier coup. Résultat : 6 mois de développement, un budget qui triple, et un produit qui ne correspond pas à ce que les utilisateurs veulent réellement. L'alternative : un MVP. Un mois. Une version minimale mais fonctionnelle. De quoi tester votre idée avec de vrais utilisateurs et prendre des décisions basées sur des faits, pas sur des suppositions. ## MVP : ce que c'est (et ce que ce n'est pas) Un MVP -- Minimum Viable Product -- n'est pas un prototype. Ce n'est pas non plus une maquette cliquable. C'est un produit réel, fonctionnel, que de vrais utilisateurs peuvent télécharger et utiliser. La différence est importante : - **Une maquette** montre à quoi l'application ressemblera. Aucune fonctionnalité ne marche réellement. - **Un prototype** démontre le concept technique. Il fonctionne, mais il n'est pas utilisable au quotidien. - **Un MVP** est une application complète, mais réduite à l'essentiel. Tout ce qui est là fonctionne parfaitement. Il n'y a simplement pas tout. L'objectif du MVP n'est pas de construire peu. C'est de construire juste. Identifier les 2 ou 3 fonctionnalités qui font la valeur de votre application, les développer impeccablement, et ignorer tout le reste pour l'instant. Un bon MVP répond à une seule question : est-ce que des gens utilisent cette application et en tirent de la valeur ? ## Semaine 1 : Cadrage et priorisation La première semaine ne produit pas une seule ligne de code. C'est la semaine la plus importante du projet. ### Définir le problème, pas la solution Avant de parler de fonctionnalités, on définit précisément le problème que vous résolvez. Pour qui ? Dans quelle situation ? Quelle est l'alternative actuelle (souvent un tableur, un processus manuel, ou rien du tout) ? Si vous ne pouvez pas décrire le problème en deux phrases, vous n'êtes pas prêt à développer. ### La règle des 3 fonctionnalités Listez toutes les fonctionnalités que vous imaginez. Il y en a probablement 15 à 30. Maintenant, choisissez-en 3. Maximum. Celles sans lesquelles l'application n'a aucun sens. C'est douloureux. Vous pensez que la fonctionnalité 4 est indispensable. Elle ne l'est probablement pas. Si votre application a besoin de 15 fonctionnalités pour être utile, ce n'est pas un problème de priorisation. C'est un signe que le périmètre est trop large. ### Maquettes et parcours utilisateur On dessine les écrans principaux. Pas un design final : des wireframes (des schémas simplifiés des écrans), qui montrent l'enchaînement des actions. L'utilisateur ouvre l'application, il voit quoi ? Il fait quoi ? Il arrive où ? Ces maquettes servent de cahier des charges visuel pour l'équipe de développement. Tout le monde voit la même chose. Pas d'ambiguïté. ### Choix techniques Pour un MVP mobile, la question "application native ou multiplateforme" se pose systématiquement. Notre recommandation dans 90 % des cas : **multiplateforme** avec React Native ou Flutter (des outils qui permettent de créer une seule application compatible iPhone et Android). Une seule base de code pour iOS et Android. Deux fois moins de développement, un MVP lancé deux fois plus vite. Les performances sont largement suffisantes pour un MVP. L'application native (développement séparé iOS et Android) se justifie quand votre application exploite intensivement le matériel du téléphone : réalité augmentée, traitement vidéo en temps réel, jeux. Pour une application métier, le multiplateforme est le bon choix. ### Livrables de la semaine 1 - Document de cadrage : problème, cible, proposition de valeur - Liste des 3 fonctionnalités coeur - Maquettes des écrans principaux (8 à 12 écrans) - Architecture technique validée - Planning semaine par semaine ## Semaine 2 : Développement des fonctionnalités coeur C'est la semaine la plus intensive en développement. ### Le socle technique Les premières heures sont consacrées à la mise en place de l'infrastructure : - Création du projet et configuration de l'environnement - Mise en place de l'authentification (inscription, connexion, mot de passe oublié) - Connexion à la base de données et aux API nécessaires - Navigation entre les écrans principaux Ce socle est invisible pour l'utilisateur, mais il représente 30 % du travail total. Le négliger, c'est s'assurer des problèmes à chaque étape suivante. ### Les fonctionnalités coeur Une fois le socle en place, on développe vos 3 fonctionnalités prioritaires. Chaque fonctionnalité est développée, testée et intégrée dans la journée ou le lendemain. Le travail avance vite parce que le périmètre est clair. Pas de discussion sur "est-ce qu'on ajoute aussi cette option ?". Le cadrage de la semaine 1 a tranché ces questions. ### Point quotidien Chaque jour, un point rapide de 15 minutes avec l'équipe. Qu'est-ce qui a été fait, qu'est-ce qui bloque, qu'est-ce qui est prévu demain. Vous voyez l'application prendre forme en temps réel. ### Livrables de la semaine 2 - Socle technique fonctionnel - 3 fonctionnalités coeur développées et testables - Première version utilisable en interne ## Semaine 3 : Finition et tests L'application fonctionne. Il faut maintenant qu'elle fonctionne bien. ### Interface et expérience utilisateur On passe des wireframes (les schémas initiaux) au design final. Couleurs, typographies, icônes, animations. L'objectif n'est pas de gagner un prix de design. C'est que l'application soit agréable et intuitive. Un MVP laid ne sera pas utilisé, même si les fonctionnalités sont excellentes. Les utilisateurs jugent un produit sur sa première impression. Investir dans une interface soignée n'est pas du luxe, c'est de la survie. ### Tests utilisateurs C'est le moment de mettre l'application entre les mains de 5 à 10 personnes représentatives de votre cible. Pas vos amis. Pas votre famille. Des gens qui ont le problème que vous résolvez. On observe comment ils utilisent l'application. Où ils hésitent, ce qu'ils ne trouvent pas, ce qu'ils essaient de faire et qui n'existe pas encore. Chaque test utilisateur révèle des problèmes que vous n'aviez pas anticipés. Les corrections issues de ces tests sont intégrées dans la foulée. Les plus critiques sont corrigées en quelques heures. Les améliorations moins urgentes sont notées pour la prochaine version. ### Tests techniques En parallèle des tests utilisateurs, l'équipe de développement vérifie : - **La performance** : l'application se lance en moins de 3 secondes, les écrans se chargent instantanément - **La stabilité** : pas de crash, pas de comportement inattendu - **La sécurité** : les données sont protégées, l'authentification est solide - **La compatibilité** : l'application fonctionne sur les différentes tailles d'écran, les versions récentes d'iOS et Android ### Livrables de la semaine 3 - Interface design finalisée - Retours de 5-10 testeurs intégrés - Application stable et performante - Bugs critiques corrigés ## Semaine 4 : Lancement L'application est prête. Il faut maintenant la mettre entre les mains de vos vrais utilisateurs. ### Publication sur les stores La soumission sur l'App Store (Apple) et le Play Store (Google) demande de la préparation : - Captures d'écran aux bons formats - Description optimisée pour le référencement - Icône de l'application - Politique de confidentialité (obligatoire) Attention : Apple prend en moyenne 24 à 48 heures pour valider une application. Google est généralement plus rapide, quelques heures à un jour. Prévoyez ces délais dans votre planning. ### Monitoring et support Les premiers jours après le lancement sont critiques. On surveille : - Les crashs en temps réel - Les retours utilisateurs - Les métriques d'utilisation : combien de personnes téléchargent, combien créent un compte, combien reviennent le lendemain Un problème détecté le premier jour se corrige en quelques heures. Un problème détecté au bout d'un mois a déjà fait partir vos premiers utilisateurs. ### Communication du lancement Le meilleur MVP du monde ne sert à rien si personne ne le sait. Préparez votre communication : - Email à votre liste de contacts intéressés - Post sur LinkedIn et vos réseaux professionnels - Message direct aux 20 personnes qui vous ont dit "préviens-moi quand c'est prêt" L'objectif n'est pas de faire le buzz. C'est d'atteindre 50 à 100 utilisateurs actifs dans les deux premières semaines. Assez pour valider vos hypothèses. ### Livrables de la semaine 4 - Application publiée sur App Store et Play Store - Système de monitoring en place - Premiers utilisateurs actifs - Tableau de bord des métriques clés ## Et après le MVP ? Le lancement du MVP n'est pas la fin. C'est le début du vrai travail. ### Collecter les retours Les deux premières semaines après le lancement, votre priorité absolue est d'écouter vos utilisateurs. Qu'est-ce qu'ils utilisent ? Qu'est-ce qu'ils ignorent ? Qu'est-ce qu'ils demandent ? Ces retours valent plus que n'importe quelle étude de marché. Ce sont des gens qui utilisent réellement votre produit et qui vous disent ce qui manque. ### Itérer rapidement Sur la base des retours, vous planifiez les prochaines évolutions. Une mise à jour toutes les deux semaines, avec des améliorations concrètes. Vos utilisateurs voient que le produit évolue. Ça crée de la confiance et de la fidélité. ### Décider de la suite Après 4 à 6 semaines d'utilisation réelle, vous avez assez de données pour prendre une décision stratégique : - **Les métriques sont bonnes** : investissez dans la version complète. Ajoutez les fonctionnalités que vous aviez mises de côté. - **Les métriques sont moyennes** : pivotez. Changez l'angle, ajustez la cible, modifiez les fonctionnalités clés. - **Personne n'utilise l'application** : vous venez d'économiser 6 mois et 50 000 euros en découvrant ça en 4 semaines plutôt qu'en un an. Dans les trois cas, le MVP a rempli son rôle. ## Quel budget prévoir ? Un MVP mobile développé en 4 semaines coûte entre 8 000 et 15 000 euros, selon la complexité des fonctionnalités et le niveau de design attendu. Ce budget comprend : - Le cadrage et les maquettes - Le développement multiplateforme (iOS + Android) - Le design de l'interface - Les tests et corrections - La publication sur les stores - Une semaine de support post-lancement Les coûts récurrents après le lancement : 200 à 500 euros par mois pour l'hébergement et les services tiers, plus le budget de maintenance et d'évolution que vous décidez d'allouer. C'est un investissement significatif, mais incomparablement plus raisonnable que les 6 mois et 40 000 à 80 000 euros d'un développement complet lancé sans validation préalable. ## Passez à l'action Vous avez une idée d'application mobile. Vous voulez la tester rapidement sans risquer votre budget sur un développement de 6 mois. L'approche MVP est faite pour ça. Chez Algomax, nous accompagnons les fondateurs dans le [développement d'applications mobiles](/services/application-mobile), du cadrage initial au lancement sur les stores. Prenez rendez-vous pour un appel découverte gratuit. On regarde votre idée, on identifie les fonctionnalités coeur de votre MVP, et on vous propose un planning et un budget précis. En 30 minutes, vous saurez exactement ce qu'il faut pour transformer votre idée en application. --- ## SaaS avec IA intégrée : votre avantage concurrentiel en 2026 URL: https://algomax.fr/blog/saas-avec-ia-integree-votre-avantage-concurrentiel-en-2026 Publié le : 2026-02-25 Description : Pourquoi et comment intégrer l'intelligence artificielle dans votre plateforme SaaS. RAG, copilots, analytics prédictif : les fonctionnalités IA qui font la différence. # SaaS avec IA intégrée : votre avantage concurrentiel en 2026 Vos concurrents vendent le même type de logiciel que vous. Les mêmes fonctionnalités, les mêmes intégrations, les mêmes grilles tarifaires. Votre client compare deux interfaces, hésite, et choisit souvent le moins cher. Maintenant, imaginez que votre SaaS ne se contente pas de stocker et d'afficher des données. Il les analyse, suggère des actions, automatise des tâches répétitives, et aide vos utilisateurs à prendre de meilleures décisions. Votre concurrent affiche un tableau. Vous, vous affichez un tableau avec une recommandation concrète en dessous. C'est exactement ce que l'intelligence artificielle apporte à un SaaS. Pas un gadget marketing. Un avantage fonctionnel tangible qui justifie un prix plus élevé et réduit le taux de désabonnement. Chez Algomax, nous construisons des [plateformes SaaS avec IA intégrée](/services/application-saas-ia) depuis que les modèles de langage sont devenus accessibles aux entreprises. Voici ce que nous avons appris. ## Pourquoi intégrer l'IA dans un SaaS maintenant Trois facteurs rendent l'intégration d'IA dans un SaaS non seulement possible, mais rentable en 2026. ### Les coûts ont chuté En 2023, un appel API à GPT-4 coûtait environ 0,06 dollar pour 1 000 tokens (les unités de texte que l'IA traite, comparables à des mots). En 2026, les modèles équivalents coûtent 10 à 20 fois moins cher. Traiter une requête utilisateur revient à moins d'un centime. Sur un abonnement à 99 euros par mois, le coût IA par utilisateur représente 2 à 5 euros. La marge reste confortable. ### Les utilisateurs s'y attendent Vos clients utilisent ChatGPT, Copilot, Gemini au quotidien. Ils s'attendent à retrouver ce niveau d'intelligence dans leurs outils professionnels. Un SaaS sans aucune couche d'IA commence à paraître daté. Pas encore obsolète, mais la tendance est claire. ### Les outils sont matures Il y a deux ans, intégrer de l'IA dans un produit demandait une équipe d'experts en données. Aujourd'hui, les API sont stables, la documentation est solide, et les méthodes d'intégration sont bien établies. Un développeur expérimenté peut ajouter une fonctionnalité IA significative en quelques semaines. ## 5 fonctionnalités IA qui changent la donne Toutes les fonctionnalités IA ne se valent pas. Certaines impressionnent en démo mais n'apportent rien au quotidien. Voici les cinq qui créent une valeur réelle et mesurable pour vos utilisateurs. ### 1. Recherche intelligente avec RAG Le problème classique : votre SaaS accumule des données depuis des mois. Vos utilisateurs ne retrouvent plus rien. Le moteur de recherche basique cherche des mots-clés exacts et rate la moitié des résultats pertinents. Le RAG (Retrieval Augmented Generation) résout ce problème. Au lieu de chercher des mots, il cherche du sens. Votre utilisateur tape "les clients qui ont eu des problèmes de livraison le mois dernier" et obtient une réponse précise, même si aucun champ ne contient exactement ces mots. Nous avons écrit un [guide détaillé sur le fonctionnement du RAG](/blog/rag-comment-agent-ia-apprend-vos-donnees) si vous voulez comprendre la mécanique. Le coût d'implémentation : entre 3 000 et 8 000 euros selon la complexité de vos données. Le coût de fonctionnement : négligeable, quelques euros par mois pour la base vectorielle (une base de données spécialisée pour l'IA) et les appels API. ### 2. Copilot intégré Un copilot (un assistant IA intégré à votre logiciel) aide vos utilisateurs directement depuis l'interface de votre SaaS. Pas un chatbot générique. Un assistant qui connaît le contexte de ce que fait l'utilisateur à l'instant T. Exemples concrets : - Dans un CRM, le copilot suggère le meilleur moment pour relancer un prospect en analysant l'historique des interactions - Dans un outil de gestion de projet, il résume les mises à jour de la semaine et identifie les tâches en retard - Dans un logiciel comptable, il détecte les anomalies dans les écritures et propose des corrections Le copilot ne remplace pas l'utilisateur. Il lui fait gagner du temps et réduit les erreurs. Les SaaS qui intègrent un copilot observent une augmentation de 20 à 35 % du temps passé sur la plateforme. Plus d'engagement, moins de désabonnement. ### 3. Workflows automatisés intelligents Les automatisations classiques fonctionnent avec des règles simples : "si tel champ contient telle valeur, faire telle action". L'IA permet des automatisations qui comprennent le contexte. Un exemple dans un SaaS de support client : au lieu de router les tickets par mots-clés (fragile et imprécis), l'IA lit le message, comprend le problème, évalue l'urgence, et route vers le bon département. Même si le client écrit avec des fautes, dans un mélange de français et d'anglais, avec des abréviations. Un autre exemple dans un SaaS RH : l'IA analyse les candidatures entrantes, les compare aux critères du poste, et crée une shortlist avec des notes justifiées. Le recruteur passe de 2 heures de tri à 15 minutes de validation. Pour aller plus loin sur l'automatisation intelligente, consultez notre page sur les [agents IA sur mesure](/services/agent-ia-sur-mesure). ### 4. Analytics prédictif Vos tableaux de bord actuels montrent ce qui s'est passé. Le passé. L'analytics prédictif (l'analyse de vos données pour anticiper ce qui va se passer) montre ce qui va probablement arriver. Dans un SaaS e-commerce : "Ce client a 73 % de chances de ne pas renouveler sa commande ce mois-ci. Voici pourquoi." Dans un SaaS de gestion financière : "Vos dépenses suivent une trajectoire qui dépassera votre budget de 15 % d'ici mars." L'analytics prédictif transforme votre SaaS d'un outil de reporting en un outil d'aide à la décision. La valeur perçue n'est pas du tout la même. Et le prix que vos clients sont prêts à payer non plus. ### 5. Génération de contenu contextuel Vos utilisateurs passent du temps à rédiger : emails, rapports, descriptions, commentaires. L'IA peut pré-rédiger ces contenus en se basant sur les données déjà présentes dans votre plateforme. Un SaaS de gestion immobilière qui génère automatiquement les descriptions d'annonces à partir des caractéristiques du bien. Un SaaS de consulting qui pré-rédige les comptes-rendus de réunion à partir des notes prises pendant le call. Un outil de recrutement qui rédige les messages d'approche LinkedIn en analysant le profil du candidat et la fiche de poste. Ce n'est pas de la génération générique. Le contenu est personnalisé, contextualisé, et directement exploitable. L'utilisateur ajuste plutôt que de rédiger de zéro. ## Combien ça coûte d'ajouter de l'IA Les coûts se décomposent en trois catégories. ### Développement initial L'intégration d'une fonctionnalité IA dans un SaaS existant ou en cours de construction coûte entre 5 000 et 15 000 euros par fonctionnalité, selon la complexité. | Fonctionnalité | Budget estimé | Délai | |---|---|---| | Recherche RAG | 3 000 - 8 000 euros | 2-4 semaines | | Copilot basique | 5 000 - 10 000 euros | 3-5 semaines | | Workflows IA | 4 000 - 12 000 euros | 3-6 semaines | | Analytics prédictif | 8 000 - 15 000 euros | 4-8 semaines | | Génération de contenu | 3 000 - 7 000 euros | 2-4 semaines | ### Coûts de fonctionnement Les API d'IA facturent à l'usage. Voici des ordres de grandeur pour un SaaS de 500 utilisateurs actifs : - **Modèles de langage** (GPT-4o, Claude) : 50 à 300 euros/mois - **Base vectorielle** (une base de données spécialisée pour l'IA, utilisée par le RAG) : 20 à 100 euros/mois - **Embeddings** (transformation de vos textes en données compréhensibles par l'IA) : 5 à 20 euros/mois - **Total** : 75 à 420 euros/mois Rapporté à 500 utilisateurs, ça représente 0,15 à 0,84 euro par utilisateur et par mois. Largement absorbable par votre tarification. ### ROI attendu Les SaaS avec IA intégrée observent trois bénéfices mesurables : - **Réduction du churn (le taux de désabonnement de vos clients)** : -15 à 30 %. Les utilisateurs qui bénéficient de l'IA sont plus engagés et restent plus longtemps - **Upsell (montée en gamme) facilité** : l'IA justifie un plan premium à un prix supérieur. On voit des écarts de 30 à 80 % entre le plan standard et le plan avec IA - **Acquisition accélérée** : "avec IA intégrée" est un argument de vente puissant dans les comparatifs et les démos Sur un SaaS à 200 clients payant 99 euros/mois, une réduction du churn de 20 % représente environ 47 000 euros de revenus préservés par an. Le développement IA est rentabilisé en quelques mois. ## L'approche d'intégration recommandée Ne construisez pas toutes les fonctionnalités IA en même temps. Voici l'approche que nous recommandons chez Algomax. ### Phase 1 : Une fonctionnalité, un impact Choisissez la fonctionnalité IA qui apporte le plus de valeur immédiate à vos utilisateurs. En général, c'est la recherche RAG ou la génération de contenu, parce que le bénéfice est visible dès la première utilisation. Développement : 3 à 5 semaines. Budget : 5 000 à 10 000 euros. ### Phase 2 : Mesurer et ajuster Déployez auprès d'un groupe pilote. Mesurez l'adoption, la satisfaction, l'impact sur le churn et l'engagement. Ajustez. Cette phase dure 4 à 8 semaines. ### Phase 3 : Étendre Une fois la première fonctionnalité validée, ajoutez les suivantes. Le copilot, les workflows automatisés, l'analytics prédictif. Chaque ajout renforce la valeur perçue et la différenciation. ### Phase 4 : Le plan premium Regroupez les fonctionnalités IA dans un plan tarifaire supérieur. Vos clients existants qui n'ont pas encore l'IA deviennent des prospects pour l'upsell. Vos nouveaux clients voient un argument de différenciation clair dans les comparatifs. ## SaaS classique ou SaaS avec IA dès le départ ? Si vous en êtes au stade de l'idée, la question se pose : faut-il intégrer l'IA dès la première version ou l'ajouter plus tard ? Notre recommandation : construisez l'architecture pour l'IA dès le départ, même si vous n'activez pas toutes les fonctionnalités au lancement. Ça signifie une base de données structurée pour le vectoriel, des API pensées pour l'intégration IA, et un modèle de données propre. Ajouter de l'IA à un SaaS mal architecturé coûte deux à trois fois plus cher que de l'intégrer dès la conception. Si vous savez que l'IA fera partie de votre produit à terme, anticipez. Pour un SaaS complet avec IA intégrée dès la conception, consultez notre offre de [développement SaaS avec IA](/services/application-saas-ia). Et si vous cherchez d'abord à construire le socle, notre page sur le [développement SaaS classique](/services/application-saas) détaille notre approche. ## Passez à l'action L'IA dans un SaaS n'est plus un luxe réservé aux startups financées. C'est un investissement accessible qui se rentabilise en quelques mois. Vous avez un SaaS existant que vous voulez enrichir avec de l'IA ? Ou un projet de SaaS que vous voulez lancer avec une couche intelligente dès le départ ? Chez Algomax, nous faisons les deux. Prenez rendez-vous pour un appel découverte gratuit. On analyse votre produit, on identifie les fonctionnalités IA les plus impactantes pour votre cas, et on vous propose un plan d'action chiffré. --- ## Créer une application SaaS : le guide pratique pour fondateurs URL: https://algomax.fr/blog/creer-une-application-saas-le-guide-pratique-pour-fondateurs Publié le : 2026-02-24 Description : Tout ce qu'un fondateur non-technique doit savoir pour lancer une plateforme SaaS. Budget, délais, stack technique, erreurs à éviter et étapes clés. # Créer une application SaaS : le guide pratique pour fondateurs Vous avez une idée de logiciel en ligne. Vos clients paieraient un abonnement mensuel pour l'utiliser. Vous voyez le potentiel. Mais entre l'idée et le produit qui tourne, il y a un fossé que beaucoup de fondateurs sous-estiment. Le modèle SaaS est devenu le standard pour vendre du logiciel. Slack, Notion, HubSpot : tous fonctionnent sur le même principe. Mais construire une plateforme SaaS n'est pas construire un site web. Les enjeux techniques, financiers et stratégiques sont différents. Ce guide est écrit pour les fondateurs non-techniques. Pas de jargon inutile, pas de slides d'investisseur. Juste ce que vous devez savoir pour prendre des décisions éclairées avant de dépenser votre premier euro. ## C'est quoi un SaaS, concrètement ? SaaS signifie "Software as a Service". En français : un logiciel accessible en ligne, via un navigateur ou une application, moyennant un abonnement. Au lieu d'acheter un logiciel une fois et de l'installer sur votre ordinateur (comme on faisait avec Microsoft Office il y a 15 ans), vos clients paient chaque mois pour y accéder. Le logiciel tourne sur des serveurs, pas sur leur machine. Vous gérez les mises à jour, la maintenance, l'hébergement. Trois caractéristiques définissent un SaaS : - **Multi-utilisateurs** : plusieurs clients utilisent la même plateforme, chacun avec ses propres données isolées - **Abonnement récurrent** : facturation mensuelle ou annuelle, pas d'achat unique - **Accessible partout** : un navigateur suffit, rien à installer Le modèle est attractif pour une raison simple : les revenus récurrents. Un client qui paie 99 euros par mois vous rapporte 1 188 euros par an, chaque année, sans effort de revente. Si vous atteignez 200 clients, c'est 240 000 euros de revenu annuel récurrent. Prévisible. Bancable. ## Les fonctionnalités indispensables d'un SaaS Avant de penser aux fonctionnalités métier (celles qui rendent votre produit unique), il y a un socle technique que tout SaaS doit avoir. C'est la partie invisible, mais elle représente souvent 40 à 50 % du travail de développement. ### Authentification et gestion des utilisateurs Vos clients doivent pouvoir créer un compte, se connecter, réinitialiser leur mot de passe, et inviter des collègues. Ça paraît simple. Ça ne l'est pas. Il faut gérer les rôles (administrateur, utilisateur standard, lecteur seul), les permissions (qui peut voir quoi), la connexion via Google ou Microsoft, l'authentification à deux facteurs. Et tout ça doit être sécurisé, parce qu'une faille sur l'authentification, c'est la fin de votre crédibilité. ### Paiement et facturation Abonnement mensuel, annuel, avec période d'essai, avec réduction, avec montée en gamme automatique quand le client dépasse un seuil d'utilisation. Le système de facturation d'un SaaS est un projet à lui seul. Stripe est devenu le standard pour gérer les paiements SaaS. Il gère les abonnements, les factures, les relances en cas d'échec de paiement, la conformité fiscale européenne. C'est un choix que nous recommandons systématiquement. ### Tableau de bord et analytics Chaque client veut voir ses données. Un tableau de bord clair, avec des indicateurs pertinents, est ce qui transforme un outil utile en outil indispensable. Si votre client ouvre votre SaaS chaque matin pour consulter son tableau de bord, vous avez gagné. ### Administration et back-office Vous avez besoin d'un panneau d'administration pour gérer vos clients, voir les abonnements actifs, intervenir en cas de problème. C'est votre cockpit. Il n'est pas visible par vos clients, mais il est essentiel pour opérer le produit au quotidien. ### Infrastructure et performance Un SaaS doit être disponible 24h/24. Si votre plateforme tombe à 10h un mardi matin, vos clients ne peuvent plus travailler. L'hébergement, la base de données, les sauvegardes, la surveillance en continu : tout ça doit être pensé dès le départ. ## Combien ça coûte ? C'est la question qui arrive en premier dans chaque appel découverte. La réponse honnête : ça dépend. Mais voici des fourchettes réalistes basées sur notre expérience. ### MVP (Minimum Viable Product) : 10 000 à 20 000 euros Le MVP, c'est la version minimale de votre produit. Juste assez pour valider que des clients sont prêts à payer. On parle de : - Authentification basique - 2 à 3 fonctionnalités coeur de métier - Paiement par Stripe - Un tableau de bord simple - Hébergement cloud Le développement prend 4 à 8 semaines avec une équipe expérimentée. L'objectif n'est pas d'avoir un produit parfait. C'est d'avoir un produit testable. ### Produit complet : 20 000 à 50 000 euros Une fois le MVP validé, vous investissez dans la version complète. On ajoute : - Gestion avancée des rôles et permissions - Intégrations avec d'autres outils (CRM, email, comptabilité) - Tableaux de bord avancés avec exports - Application mobile ou interface responsive poussée - Multi-langue, multi-devise - Documentation et guide de prise en main intégré à l'application Le développement prend 3 à 6 mois. Ce n'est pas un gros bang : on livre par itérations, fonctionnalité par fonctionnalité. ### Coûts récurrents : 500 à 3 000 euros par mois Une fois lancé, votre SaaS a des coûts fixes : - **Hébergement cloud** : 100 à 500 euros/mois selon le volume - **Services tiers** (Stripe, email, surveillance) : 100 à 300 euros/mois - **Maintenance et support technique** : 300 à 2 000 euros/mois - **Mises à jour et évolutions** : variable selon vos ambitions ## Le calendrier réaliste Voici un calendrier type pour un SaaS lancé de zéro : ### Semaines 1-2 : Cadrage et spécifications On définit précisément ce que le MVP doit faire. Pas ce qu'il pourrait faire un jour. Ce qu'il doit faire pour que vous puissiez le mettre entre les mains de vos 10 premiers clients. Cette phase produit un document de spécifications, des maquettes d'interface, et un planning détaillé. C'est le moment où on challenge vos idées. Certaines fonctionnalités que vous pensez essentielles ne le sont pas. D'autres que vous n'avez pas envisagées sont critiques. ### Semaines 3-8 : Développement du MVP Le développement se fait par sprints (des cycles de travail courts) de deux semaines. Chaque sprint produit une version fonctionnelle que vous pouvez tester. Vous voyez le produit avancer concrètement, pas juste des rapports d'avancement. ### Semaines 9-10 : Tests et corrections Test en conditions réelles avec vos premiers utilisateurs. On corrige les bugs, on ajuste l'interface, on peaufine les performances. Cette phase est souvent compressée par les fondateurs pressés. C'est une erreur. Un lancement avec des bugs visibles détruit la confiance de vos premiers clients. ### Semaine 11 : Lancement Mise en production, surveillance renforcée, support réactif pendant les premiers jours. Le lancement n'est pas la fin du projet, c'est le début. ## Les 5 erreurs qui coûtent cher ### 1. Vouloir tout construire dès le départ Le piège classique. Vous avez 50 idées de fonctionnalités. Vous voulez toutes les intégrer dans la première version. Résultat : 9 mois de développement, un budget qui explose, et un produit que personne n'utilise parce que vous n'avez jamais validé la demande. Lancez petit. Ajoutez ensuite. ### 2. Négliger le socle technique Authentification bricolée, base de données mal structurée, pas de tests automatisés. On économise 3 000 euros au départ, on en dépense 30 000 pour tout refaire six mois plus tard. Le socle technique d'un SaaS, c'est la fondation d'une maison. Invisible, mais si c'est bâclé, tout s'effondre. ### 3. Choisir le mauvais prestataire Un développeur freelance à 200 euros par jour peut sembler économique. Mais s'il disparaît en cours de projet, ou si son code est illisible pour le prochain développeur, vous perdez tout. Vérifiez les références, demandez à voir des projets SaaS déjà livrés, exigez une documentation technique. ### 4. Ignorer la sécurité Un SaaS stocke les données de vos clients. Une fuite de données, c'est une catastrophe légale (RGPD) et réputationnelle. La sécurité n'est pas une option qu'on ajoute plus tard. Elle se pense dès la conception. ### 5. Pas de plan pour l'après-lancement Le jour du lancement, votre produit est à 20 % de son potentiel. Les 80 % restants se construisent avec les retours de vos utilisateurs. Prévoyez un budget de maintenance et d'évolution. Un SaaS sans mises à jour régulières est un SaaS qui meurt. ## Comment choisir votre partenaire de développement Le choix de l'équipe de développement est probablement la décision la plus importante que vous prendrez. Voici les critères qui comptent vraiment. ### Expérience SaaS spécifique Construire un SaaS n'est pas construire un site vitrine. Votre prestataire doit avoir déjà livré des plateformes SaaS en production, avec de vrais utilisateurs qui paient. Demandez des références concrètes. ### Technologies modernes Les technologies évoluent vite. Un SaaS construit avec des outils obsolètes sera plus cher à maintenir et plus difficile à faire évoluer. Chez Algomax, nous utilisons des technologies modernes et éprouvées pour le web (Next.js, TypeScript, PostgreSQL) qui garantissent performance et maintenabilité à long terme. ### Transparence sur les coûts et les délais Méfiez-vous des devis vagues. Un bon prestataire vous donne un budget détaillé par fonctionnalité, un calendrier semaine par semaine, et vous prévient quand un choix coûte plus cher que prévu. Pas de surprise à la facture finale. ### Transfert de compétences Votre code vous appartient. Votre prestataire doit vous donner accès au code source, documenter son travail, et vous permettre de changer de prestataire si nécessaire. Vous ne devez jamais être prisonnier d'un fournisseur. ## Et si votre SaaS intégrait de l'IA ? En 2026, les SaaS les plus compétitifs intègrent de l'intelligence artificielle. Pas pour le buzz, mais pour apporter une valeur réelle : analytics prédictif, copilots pour aider vos utilisateurs, automatisation intelligente des tâches répétitives. Si vous envisagez d'ajouter une couche d'IA à votre plateforme, nous avons écrit un article dédié sur les [SaaS avec IA intégrée](/blog/saas-avec-ia-avantage-concurrentiel) qui détaille les possibilités et les coûts. ## Passez à l'action Vous avez une idée de SaaS. Vous savez maintenant ce que ça implique en termes de budget, de délais et de complexité. La prochaine étape, c'est de transformer cette idée en spécifications concrètes. Chez Algomax, nous accompagnons les fondateurs de l'idée au lancement. Notre expertise couvre le [développement de plateformes SaaS](/services/application-saas) et les [SaaS avec intelligence artificielle intégrée](/services/application-saas-ia). Prenez rendez-vous pour un appel découverte gratuit de 30 minutes. On regarde votre idée ensemble, on vous dit ce qui est réaliste, et on vous propose un plan d'action chiffré. Sans engagement. --- ## RAG : comment un agent IA apprend vos données URL: https://algomax.fr/blog/rag-comment-agent-ia-apprend-vos-donnees Publié le : 2026-02-23 Description : Le Retrieval Augmented Generation permet à un agent IA de répondre en s'appuyant sur vos documents internes. Fonctionnement technique, coûts réels et limites. # RAG : comment un agent IA apprend vos données Vos équipes passent 2h par jour à chercher des réponses dans des PDFs, des pages Notion et des wikis Confluence. Vous avez essayé ChatGPT. Il invente des réponses parce qu'il ne connaît pas vos données internes. Le problème n'est pas le modèle. C'est l'absence de contexte. Le RAG -- Retrieval Augmented Generation -- résout exactement ce problème. Au lieu de tout mémoriser, l'IA cherche dans vos documents au moment de répondre. Pas de formation coûteuse du modèle. Pas d'hallucinations sur vos données métier. Juste une recherche intelligente couplée à la génération de texte. Chez Algomax, nous avons déployé des systèmes RAG pour des entreprises de 20 à 500 employés. Cet article vous explique comment ça fonctionne, ce que ça coûte, et surtout où ça coince. ## Pourquoi pas simplement entraîner le modèle ? La question revient à chaque appel découverte. "On ne peut pas juste donner nos documents à GPT pour qu'il apprenne ?" Techniquement, oui. Ça s'appelle le fine-tuning. Et dans 90 % des cas, c'est la mauvaise approche pour des données d'entreprise. Voici pourquoi. Le fine-tuning modifie les poids du modèle. Vous payez l'entraînement (plusieurs centaines de dollars par session), vous attendez des heures, et dès que vos documents changent, vous recommencez. Pour une base de connaissances qui évolue chaque semaine, c'est un gouffre. Le RAG ne modifie rien dans le modèle. Il ajoute une étape de recherche avant la génération. Vos documents sont indexés dans une base de données vectorielle. Quand un utilisateur pose une question, le système retrouve les passages pertinents et les injecte dans le prompt. Le modèle répond en s'appuyant sur ces extraits. Les avantages concrets : - **Mise à jour instantanée.** Un nouveau document ? Il est indexé en quelques secondes et disponible immédiatement. - **Traçabilité.** Chaque réponse peut citer sa source. Vous savez d'où vient l'information. - **Coût prévisible.** L'indexation coûte environ 0,10 $ par million de tokens. Indexer 10 000 pages de documentation revient à moins de 5 $. - **Pas de dégradation.** Le fine-tuning peut dégrader les capacités générales du modèle. Le RAG n'y touche pas. Le fine-tuning reste pertinent pour modifier le style ou le comportement du modèle. Mais pour connecter une IA à vos données, le RAG est plus rapide, moins cher et plus fiable. ## Comment ça fonctionne, étape par étape Derrière le terme RAG, il y a un pipeline en six étapes. Aucune n'est optionnelle. ### 1. Ingestion des documents Première étape : collecter vos données. PDFs, pages Notion, articles Confluence, tickets Zendesk, emails archivés, fichiers Google Docs. Chaque source nécessite un connecteur spécifique pour extraire le texte brut. C'est souvent la partie la plus sous-estimée. Un PDF scanné sans OCR ne contient aucun texte exploitable. Un export Confluence mal formaté perd ses tableaux. Nous passons typiquement 30 % du temps projet sur cette étape. ### 2. Découpage en chunks Un document de 50 pages ne rentre pas dans le contexte d'un LLM. Il faut le découper en morceaux -- des "chunks" -- de taille exploitable. La taille standard : entre 500 et 1 500 tokens par chunk. Trop petit, vous perdez le contexte. Trop grand, vous diluez la pertinence de la recherche. Nous utilisons un découpage avec chevauchement (overlap de 10-15 %) pour éviter de couper une idée en deux. Le découpage intelligent tient aussi compte de la structure : titres, paragraphes, listes. Un chunk qui commence au milieu d'une phrase est un chunk inutile. ### 3. Transformation en embeddings Chaque chunk est converti en un vecteur numérique -- une liste de 1 536 nombres (avec le modèle `text-embedding-3-small` d'OpenAI, par exemple). Ces vecteurs capturent le sens sémantique du texte. Deux phrases qui disent la même chose avec des mots différents auront des vecteurs proches. "Notre politique de remboursement" et "comment se faire rembourser" pointent vers la même zone dans l'espace vectoriel. Le coût est négligeable : environ 0,02 $ pour un million de tokens avec les modèles récents. Indexer toute la documentation d'une PME coûte rarement plus de 1 $. ### 4. Stockage dans une base vectorielle Les vecteurs sont stockés dans une base de données spécialisée. Pas MySQL. Pas PostgreSQL (bien que pgvector existe). Une base conçue pour la recherche de similarité sur des vecteurs à haute dimension. Les options que nous utilisons chez Algomax : - **Pinecone** : hébergé, simple à déployer, 20 $/mois pour démarrer. Idéal pour un premier projet. - **Qdrant** : open source, auto-hébergeable, plus de contrôle. Nous le recommandons quand les données sont sensibles. - **pgvector** : extension PostgreSQL, pratique si vous voulez tout garder dans une seule base. Performances acceptables jusqu'à quelques centaines de milliers de chunks. Pour une base de connaissances de 5 000 à 50 000 documents, comptez entre 20 et 100 $ par mois d'hébergement vectoriel. ### 5. Recherche (retrieval) Quand un utilisateur pose une question, elle est convertie en vecteur avec le même modèle d'embedding. La base vectorielle retourne les 3 à 10 chunks les plus proches sémantiquement. C'est ici que la qualité se joue. Un bon retrieval retourne les passages réellement pertinents. Un mauvais retrieval noie le modèle dans du bruit. Nous ajoutons souvent une étape de re-ranking : un second modèle, plus petit, qui reclasse les résultats par pertinence. Le gain est mesurable -- on passe typiquement de 70 % à 85 % de pertinence sur les 3 premiers résultats. ### 6. Génération de la réponse Les chunks récupérés sont injectés dans le prompt du LLM avec la question de l'utilisateur. Le modèle génère une réponse en s'appuyant sur ces extraits. Le prompt est structuré pour forcer le modèle à citer ses sources et à dire "je ne sais pas" quand l'information n'est pas dans les documents fournis. Sans cette contrainte, le modèle invente. Avec elle, le taux d'hallucination sur les données internes tombe sous les 5 %. ## Exemple concret : un bot FAQ sur vos documents internes Un de nos clients -- une entreprise SaaS de 80 personnes -- avait 400 pages de documentation produit réparties entre Notion et Google Docs. Leur équipe support répondait aux mêmes questions 15 fois par jour. Nous avons déployé un [agent IA sur mesure](/services/agent-ia-sur-mesure) connecté à leur base documentaire. Le pipeline : 1. Connecteurs Notion et Google Docs avec synchronisation toutes les 15 minutes 2. Découpage en chunks de 800 tokens avec overlap de 100 tokens 3. Embeddings via `text-embedding-3-small` d'OpenAI 4. Stockage dans Qdrant auto-hébergé (données sensibles) 5. Re-ranking avec Cohere Rerank 6. Génération avec Claude d'Anthropic Résultat : 73 % des questions support traitées sans intervention humaine. Le bot cite systématiquement la page source. Quand il ne trouve pas la réponse, il escalade vers un humain au lieu d'inventer. Le projet a pris 3 semaines. Le coût d'exploitation : environ 150 $/mois tout compris (embeddings + vector DB + API LLM). C'est le même principe que pour [automatiser un service client avec un agent IA](/blog/automatiser-service-client-agent-ia), mais appliqué à la documentation interne. ## Notre stack technique Chez Algomax, nous construisons les pipelines RAG en Node.js/TypeScript. Le choix est pragmatique : c'est le même langage que le reste de l'application de nos clients, ce qui simplifie la maintenance. - **LLM** : Claude (Anthropic) ou GPT-4o (OpenAI) selon le cas d'usage. Claude excelle sur les documents longs. GPT-4o est plus rapide pour les réponses courtes. - **Embeddings** : `text-embedding-3-small` d'OpenAI pour le rapport qualité/prix. `text-embedding-3-large` quand la précision justifie le surcoût. - **Vector DB** : Qdrant pour les projets sensibles, Pinecone pour les déploiements rapides. - **Orchestration** : LangChain ou appels directs aux APIs selon la complexité. Nous évitons LangChain quand le pipeline est simple -- c'est une abstraction qui ajoute de la complexité sans bénéfice sur les cas basiques. ## Les limites que personne ne mentionne Le RAG n'est pas magique. Voici ce qui coince en production. **La qualité dépend de vos données.** Si votre documentation est obsolète, contradictoire ou mal structurée, le RAG va fidèlement retourner des informations obsolètes, contradictoires ou mal structurées. Garbage in, garbage out. Nous recommandons un audit de la base documentaire avant tout déploiement. **Le chunking est un compromis permanent.** Des chunks courts améliorent la précision de la recherche mais perdent le contexte. Des chunks longs gardent le contexte mais diluent la pertinence. Il n'y a pas de taille universelle -- chaque base documentaire nécessite des tests. **Les requêtes multi-hop sont difficiles.** "Quel client a le contrat le plus élevé dans la région Ouest et quand expire-t-il ?" Cette question nécessite de croiser plusieurs documents. Le RAG basique ne sait pas faire ça. Il faut ajouter des agents avec des étapes de raisonnement, ce qui complexifie le système. **Le multilingue reste un défi.** Les embeddings fonctionnent mieux en anglais. Une base documentaire en français avec des termes techniques spécifiques à votre industrie donnera des résultats moins précis. Les modèles multilingues progressent, mais l'écart existe encore. **La latence s'additionne.** Embedding de la question (50 ms) + recherche vectorielle (100 ms) + re-ranking (200 ms) + génération LLM (1-3 s). Comptez 2 à 4 secondes pour une réponse complète. C'est acceptable pour un chatbot, moins pour une API temps réel. ## Quand le RAG ne suffit pas Le RAG excelle pour retrouver et synthétiser de l'information existante. Il atteint ses limites quand vous avez besoin de : - **Raisonnement complexe** sur des données structurées (utilisez SQL + LLM) - **Calculs** à partir de vos données (le LLM n'est pas une calculatrice fiable) - **Actions** dans vos systèmes (il faut un agent avec des outils, pas juste du RAG) - **Analyse de tendances** sur des séries temporelles (utilisez des outils analytiques classiques) Dans ces cas, le RAG devient un composant d'une architecture plus large, pas la solution complète. ## Par où commencer Si vous envisagez un système RAG pour votre entreprise, commencez par trois questions : 1. Vos documents sont-ils numériques et à jour ? 2. Les questions de vos utilisateurs trouvent-elles réponse dans ces documents ? 3. Le volume de questions justifie-t-il l'investissement (même modeste) ? Si oui aux trois, un premier prototype est déployable en une à deux semaines. Nous proposons des [agents IA sur mesure](/services/agent-ia-sur-mesure) qui intègrent le RAG comme brique de base. Le plus dur n'est pas la technologie. C'est la qualité de vos données. --- ## Chatbot IA vs Agent IA : quelle différence ? URL: https://algomax.fr/blog/chatbot-ia-vs-agent-ia-quelle-difference Publié le : 2026-02-23 Description : Chatbot ou agent IA ? Comparaison honnête des cas d'usage, des coûts et des limites de chaque solution pour vous aider à faire le bon choix. # Chatbot IA vs Agent IA : quelle différence ? Vous avez un projet d'automatisation. Votre équipe perd du temps sur des tâches répétitives. Un prestataire vous propose un "agent IA". Un autre parle de "chatbot intelligent". Les deux promettent de résoudre vos problèmes. Le souci : ces termes sont utilisés n'importe comment. On voit des chatbots basiques vendus comme des "agents autonomes", et des agents surpuissants déployés là où un simple chatbot aurait fait le travail pour trois fois moins cher. Chez Algomax, nous construisons les deux. Nous savons quand l'un vaut mieux que l'autre. Voici notre grille de lecture. ## Ce qu'est réellement un chatbot IA Un chatbot IA, c'est une interface conversationnelle. Vous lui posez une question, il répond. Il peut s'appuyer sur un modèle de langage (GPT, Claude, Mistral) pour comprendre des formulations variées, mais son périmètre reste défini. Concrètement, un [chatbot IA](/services/chatbot-ia) fait bien ces choses : - **Répondre aux questions fréquentes.** Horaires, tarifs, politique de retour, procédures internes. Il puise dans une base de connaissances que vous alimentez. - **Qualifier un prospect.** Il pose quelques questions, collecte un email, oriente vers le bon interlocuteur. - **Prendre un rendez-vous.** Il consulte un calendrier et propose des créneaux disponibles. - **Faire du support niveau 1.** Il traite les demandes simples et escalade le reste vers un humain. Le chatbot ne prend pas de décision. Il ne modifie rien dans vos systèmes. Il répond, il oriente, il collecte. C'est tout. Et pour beaucoup d'entreprises, c'est suffisant. ## Ce qu'est réellement un agent IA Un [agent IA](/services/agent-ia) va plus loin. Il ne se contente pas de répondre : il agit. Il a accès à vos outils (CRM, ERP, base de données, API tierces) et peut enchaîner plusieurs actions pour atteindre un objectif. Quelques exemples concrets : - **Traitement de commandes.** Un client envoie un email pour modifier sa commande. L'agent comprend la demande, vérifie le stock dans l'ERP, met à jour la commande dans le CRM, envoie une confirmation au client. Quatre étapes, zéro intervention humaine. - **Onboarding client.** L'agent crée le compte, génère les accès, envoie les documents contractuels, planifie le premier appel de suivi, met à jour le pipeline commercial. - **Analyse et reporting.** L'agent collecte des données depuis plusieurs sources, les agrège, détecte des anomalies et génère un rapport avec des recommandations. - **Workflows multi-étapes.** Tout processus qui implique plus de deux systèmes et une logique conditionnelle ("si X alors Y, sinon Z"). La différence fondamentale : l'agent prend des décisions intermédiaires. Il adapte son comportement selon le contexte. Un chatbot suit un script, même sophistiqué. Un agent suit un objectif. ## La matrice de décision Voici comment nous aidons nos clients à trancher : | Critère | Chatbot IA | Agent IA | |---|---|---| | **Type d'interaction** | Questions-réponses, formulaires guidés | Actions multi-étapes, workflows autonomes | | **Accès aux systèmes** | Lecture seule (base de connaissances, calendrier) | Lecture et écriture (CRM, ERP, APIs, bases de données) | | **Prise de décision** | Aucune ou minimale (arbre de décision simple) | Oui, avec logique conditionnelle et adaptation au contexte | | **Supervision nécessaire** | Faible | Moyenne à forte selon la criticité des actions | | **Délai de mise en place** | 2 à 4 semaines | 4 à 10 semaines | | **Budget initial** | 1 000 à 5 000 EUR | 3 000 à 12 000 EUR | | **Maintenance mensuelle** | 100 à 500 EUR | 300 à 1 500 EUR | | **Complexité technique** | Faible à moyenne | Moyenne à élevée | | **Risque d'erreur** | Faible (il répond mal, c'est tout) | Modéré (il peut modifier des données réelles) | | **ROI typique** | 3 à 6 mois | 2 à 8 mois (variable selon le volume traité) | ## Quand le chatbot suffit Soyons francs. Si vos besoins sont simples, un chatbot suffit. Pas besoin de surpayer. Vous recevez 200 emails par mois avec les mêmes 15 questions ? Un chatbot bien configuré en traitera 70 à 80 %. Coût : 2 000 EUR de mise en place, 200 EUR par mois de maintenance. Votre équipe support récupère 30 heures par mois. Le calcul est vite fait. Un chatbot est le bon choix quand : - Vos processus n'impliquent qu'un seul système (votre site web, un calendrier, une FAQ). - Les réponses attendues sont relativement prévisibles. - L'erreur n'a pas de conséquence grave (une mauvaise réponse à une question FAQ, ce n'est pas la fin du monde). - Votre volume justifie l'investissement mais pas un système complexe. Nous avons eu des clients qui voulaient un agent IA pour gérer leur FAQ. Nous leur avons recommandé un chatbot. Ils ont économisé 6 000 EUR sur le développement initial. Le chatbot tourne depuis huit mois sans problème. ## Quand l'agent IA devient nécessaire L'agent devient pertinent quand le chatbot atteint ses limites. En général, c'est le moment où vous réalisez que répondre ne suffit plus : il faut agir. Signes que vous avez besoin d'un agent : - **Vos équipes passent du temps à copier-coller des données entre systèmes.** L'agent connecte ces systèmes et fait les transferts automatiquement. - **Vos processus ont des étapes conditionnelles.** "Si le client est premium, appliquer telle remise. Si le stock est bas, proposer une alternative." Un chatbot ne gère pas ça. Un agent, si. - **Vous avez besoin de traçabilité.** L'agent log chaque action, chaque décision. Vous pouvez auditer ce qu'il a fait et pourquoi. - **Le volume est élevé et les erreurs coûtent cher.** Quand vous traitez 500 demandes par jour avec un processus en quatre étapes, l'erreur humaine n'est pas un risque théorique. C'est une certitude statistique. Pour approfondir la mise en place concrète d'un agent IA dans votre organisation, nous avons rédigé un [guide pratique sur les agents IA pour entreprise](/blog/agent-ia-pour-entreprise-guide-pratique). ## La question des coûts Parlons argent. Les fourchettes dans la matrice ci-dessus sont des moyennes. Voici ce qui fait varier le prix. **Pour un chatbot IA (1 000 - 5 000 EUR) :** - Bas de fourchette : chatbot FAQ simple, une langue, intégré sur votre site. Base de connaissances de moins de 50 pages. - Haut de fourchette : chatbot multilingue avec prise de rendez-vous, qualification de leads, intégration calendrier et CRM en lecture seule. **Pour un agent IA (3 000 - 12 000 EUR) :** - Bas de fourchette : agent connecté à 2-3 systèmes, workflow linéaire, supervision humaine sur les actions critiques. - Haut de fourchette : agent multi-systèmes (5+), logique conditionnelle complexe, gestion d'exceptions, reporting automatisé. **Maintenance mensuelle :** La maintenance, c'est ce que les gens oublient. Un chatbot nécessite des mises à jour de sa base de connaissances, quelques ajustements quand les questions évoluent. Comptez 100 à 500 EUR par mois. Un agent nécessite une surveillance plus active. Les APIs évoluent, les processus métier changent, les cas limites apparaissent. Comptez 300 à 1 500 EUR par mois. Ce n'est pas négligeable. Mais comparez-le au coût d'un ETP qui fait le même travail manuellement. ## Les erreurs que nous voyons souvent **Erreur 1 : Déployer un agent quand un chatbot suffit.** Résultat : vous payez trois fois plus pour une solution qui fait la même chose, avec plus de maintenance. Un chatbot FAQ n'a pas besoin d'accéder à votre CRM. **Erreur 2 : Rester sur un chatbot quand un agent est nécessaire.** Résultat : vos équipes compensent les limites du chatbot en traitant manuellement ce qu'il ne sait pas faire. Le ROI du chatbot s'effondre parce qu'il ne couvre que 30 % du besoin. **Erreur 3 : Lancer un agent sans supervision.** Un agent qui modifie des données en production, ça se surveille. Surtout les trois premiers mois. Nous recommandons systématiquement une phase de "supervision humaine" où chaque action de l'agent est validée avant exécution. On relâche progressivement quand la confiance est établie. **Erreur 4 : Négliger la maintenance.** Un chatbot non mis à jour donne des réponses obsolètes. Un agent non maintenu peut casser quand une API tierce change. Dans les deux cas, la confiance de vos utilisateurs s'érode vite. ## Notre recommandation Commencez par le chatbot si vous n'êtes pas sûr. C'est moins cher, plus rapide à déployer, et ça vous donne des données réelles sur ce que vos utilisateurs demandent. Ces données sont précieuses pour concevoir un agent pertinent si vous en avez besoin ensuite. Si vous savez déjà que votre problème implique plusieurs systèmes et des actions concrètes, allez directement vers l'agent. Le chatbot serait une étape intermédiaire qui vous coûterait du temps. Dans les deux cas, définissez clairement le périmètre avant de commencer. "Un chatbot qui fait tout" ou "un agent qui gère tous nos processus", ça n'existe pas. On commence petit, on mesure, on étend. Vous pouvez consulter nos pages dédiées pour en savoir plus sur nos offres de [chatbot IA](/services/chatbot-ia) et d'[agent IA](/services/agent-ia). Et si vous hésitez encore, contactez-nous. On vous dira honnêtement ce dont vous avez besoin. --- ## Agent IA pour entreprise : guide pratique URL: https://algomax.fr/blog/agent-ia-pour-entreprise-guide-pratique Publié le : 2026-02-23 Description : Comment déployer un agent IA dans votre entreprise, département par département. ROI concret, cas d'usage réels et limites honnêtes. # Agent IA pour entreprise : guide pratique Votre équipe support passe 4 heures par jour à répondre aux mêmes 15 questions. Votre service comptable recopie des données de factures dans un ERP à la main. Votre commercial oublie de relancer un prospect parce qu'il a 200 leads dans son CRM et aucun système de priorisation. Ces problèmes ne sont pas nouveaux. Ce qui est nouveau, c'est qu'on peut les résoudre sans recruter. Chez Algomax, nous construisons des agents IA pour des PME et ETI françaises depuis maintenant plusieurs années. On a vu ce qui marche. On a aussi vu ce qui ne marche pas du tout. Ce guide est un condensé de cette expérience. ## Un agent IA, c'est quoi exactement ? On va faire court parce qu'on a écrit un [comparatif détaillé entre chatbot et agent IA](/blog/chatbot-ia-vs-agent-ia-quelle-difference) qui couvre le sujet en profondeur. L'idée simple : un chatbot répond à des questions. Un agent IA prend des décisions et exécute des actions. Un chatbot, c'est un formulaire intelligent. Vous posez une question, il cherche dans une base de connaissances, il vous renvoie une réponse. Point. Un agent IA va plus loin. Il peut : - Lire un email entrant, comprendre qu'il s'agit d'une réclamation, créer un ticket dans votre outil de support, classifier la priorité, et assigner le bon technicien - Analyser une facture PDF, extraire les montants, vérifier la cohérence avec le bon de commande, et pré-remplir l'écriture comptable - Surveiller votre pipeline commercial et déclencher une séquence de relance quand un deal stagne depuis 10 jours La différence fondamentale : l'agent a accès à vos outils et peut agir dedans. Il ne se contente pas de parler. ## Cas d'usage par département ### Support client C'est le cas d'usage le plus mature. Et de loin. Imaginons une PME de 20 personnes qui vend un logiciel SaaS. Elle reçoit 150 à 250 tickets par jour. Deux personnes au support, débordées. Temps de réponse moyen : 6 heures. Satisfaction client en chute. Un agent IA bien configuré traite les tickets de niveau 1 en autonomie. Réinitialisation de mot de passe, question sur une fonctionnalité, demande de facture, changement d'abonnement. Ça représente en général 60 à 70% du volume. Les chiffres qu'on observe chez nos clients : - **Temps de réponse** : de 6h à moins de 2 minutes pour les tickets automatisés - **Volume traité sans humain** : 120 à 170 tickets/jour - **Économie** : environ 1,5 à 2 ETP, soit 70 à 90k€ par an en coûts salariaux - **Coût de l'agent** : entre 800 et 2000€/mois selon la complexité Le ROI est souvent atteint en 3 à 4 mois. Parfois moins. Attention cependant. L'agent ne remplace pas vos agents humains sur les cas complexes. Un client furieux qui menace de résilier, ça demande de l'empathie humaine. L'agent doit savoir quand escalader. C'est une partie non négligeable du travail de configuration. ### Ventes et prospection Moins mature que le support, mais le potentiel est réel. Un agent commercial peut : - **Qualifier les leads entrants** : analyser le formulaire de contact, enrichir avec des données publiques (taille d'entreprise, secteur, CA estimé), scorer le lead, et router vers le bon commercial - **Relancer intelligemment** : détecter les deals inactifs dans le CRM, générer un email de relance personnalisé, planifier l'envoi au bon moment - **Préparer les rendez-vous** : compiler un brief sur le prospect (actualités récentes, concurrents, historique des échanges) 15 minutes avant le call Imaginons une équipe de 5 commerciaux avec 800 leads actifs dans le CRM. Sans agent, chaque commercial gère 160 leads. En pratique, il en suit 30 à 40 sérieusement. Les autres tombent dans l'oubli. Avec un agent qui automatise la qualification et les relances, nos clients observent une augmentation de 15 à 25% du taux de conversion sur les leads existants. Sur un panier moyen de 5000€, ça se chiffre vite. Un point honnête : l'agent commercial fonctionne bien quand vous avez déjà un processus de vente structuré. Si votre CRM est un champ de bataille avec des données incomplètes partout, l'agent ne fera pas de miracles. Nettoyez d'abord. ### Ressources humaines Le département RH est souvent le parent pauvre de l'automatisation. Pourtant les tâches répétitives y sont nombreuses. Ce qu'un agent peut faire concrètement : - **Tri des candidatures** : lire les CV, les comparer aux critères du poste, créer une shortlist. On parle de passer de 2h de tri par offre à 10 minutes de validation humaine - **Onboarding** : guider le nouveau salarié dans ses démarches administratives, répondre à ses questions sur la mutuelle, les congés, le fonctionnement interne. Disponible 24h/24, ce que votre RH ne peut pas être - **Questions récurrentes des salariés** : combien de jours de congé il me reste, comment poser un arrêt maladie, c'est quoi la politique de télétravail. Ces questions mangent un temps fou Pour une entreprise de 100+ salariés, l'agent RH économise typiquement 0,5 à 1 ETP. Pour une entreprise de 20 personnes, c'est rarement rentable en standalone. On le recommande plutôt comme brique dans un agent plus large. ### Comptabilité et finance Là où l'erreur humaine coûte cher. Un agent comptable peut : - **Traiter les factures fournisseurs** : extraction des données (OCR + IA), rapprochement avec les bons de commande, pré-saisie dans l'ERP, détection des anomalies (montant inhabituel, fournisseur inconnu) - **Relance des impayés** : identifier les factures en retard, envoyer des relances graduelles, escalader après X jours - **Reporting** : générer des tableaux de bord hebdomadaires à partir des données comptables Sur le traitement de factures, les gains sont mesurables. Une entreprise qui traite 500 factures/mois manuellement y consacre environ 1 minute par facture en saisie pure. Ajoutez le contrôle, le classement, les allers-retours. On arrive facilement à 3-4 minutes par facture. Soit 25 à 33 heures par mois. Un agent réduit ce temps de 80%. Il reste la validation humaine, mais on parle de 5 à 7 heures au lieu de 30. ## Quand un agent IA n'est PAS la bonne solution On préfère vous le dire maintenant plutôt que de vous vendre quelque chose d'inutile. **Volume trop faible.** Si vous recevez 10 tickets par jour, l'investissement dans un agent IA n'est pas justifié. Le seuil de rentabilité se situe autour de 50 à 80 interactions quotidiennes pour le support, 200+ factures/mois pour la comptabilité. En dessous, un bon outil SaaS standard fera le travail. **Processus non défini.** Un agent IA automatise un processus. Si le processus n'existe pas encore ou change toutes les semaines, commencez par le stabiliser. L'agent amplifie ce qui fonctionne. Il amplifie aussi ce qui ne fonctionne pas. **Données inexploitables.** Si votre CRM est vide, vos emails ne sont pas centralisés, et vos factures arrivent par 4 canaux différents sans nomenclature commune, l'agent passera plus de temps à chercher qu'à travailler. On recommande souvent un chantier de nettoyage de données avant le déploiement de l'agent. **Attentes irréalistes.** Un agent IA ne va pas "remplacer votre équipe". Il va absorber les tâches répétitives pour que votre équipe se concentre sur ce qui demande du jugement. Si vous cherchez à licencier tout le monde et mettre un robot, on n'est pas le bon partenaire. ## Le coût réel Soyons concrets. Parce que "ça dépend" ne vous aide pas à budgéter. Pour un agent de support client standard : - **Développement initial** : 8 000 à 25 000€ selon la complexité des intégrations - **Coût d'exploitation mensuel** : 500 à 2 000€ (infrastructure + API IA + maintenance) - **Temps de déploiement** : 4 à 8 semaines Pour un agent multi-département (support + comptabilité + CRM) : - **Développement** : 20 000 à 60 000€ - **Exploitation** : 1 500 à 4 000€/mois - **Déploiement** : 8 à 16 semaines Ces fourchettes sont larges parce que tout dépend de vos outils existants. Intégrer un agent avec un Zendesk bien configuré, c'est 3 jours. Intégrer avec un outil maison qui n'a pas d'API, c'est 3 semaines. ## Comment nous construisons ces agents Chez Algomax, notre approche est pragmatique. Pas de POC qui dort dans un tiroir. On commence par un audit rapide de vos processus. Pas 6 mois de consulting. 1 à 2 semaines pour identifier le cas d'usage à plus fort impact. Ensuite on construit un premier agent fonctionnel en 4 à 6 semaines. On le déploie en production avec des garde-fous. Et on itère. On utilise les modèles de langage les plus récents, mais ce n'est pas ça qui fait la différence. Ce qui fait la différence, c'est l'ingénierie autour : la gestion des erreurs, les fallbacks quand l'IA ne sait pas, l'intégration propre avec vos outils, et le monitoring pour détecter les dérives. Vous pouvez consulter notre [page dédiée aux agents IA](/services/agent-ia) pour le détail de notre méthodologie et nos garanties. ## Par où commencer Si vous lisez cet article, c'est que vous avez probablement un cas d'usage en tête. Voici comment valider s'il vaut le coup : 1. **Comptez le volume.** Combien de fois cette tâche est-elle réalisée par jour/semaine ? Si c'est moins de 50 fois par semaine, réfléchissez-y à deux fois. 2. **Mesurez le temps.** Combien de minutes par occurrence ? Multipliez par le volume. Si vous arrivez à moins de 10 heures par mois, un agent IA est probablement surdimensionné. 3. **Évaluez la complexité.** La tâche suit-elle des règles claires ? Si oui, c'est un bon candidat. Si chaque cas est unique et demande 20 minutes de réflexion humaine, l'agent va galérer. 4. **Vérifiez les intégrations.** Vos outils ont-ils des API ? Sans API, pas d'agent. Ou alors avec beaucoup de bricolage. Si les réponses sont favorables, vous tenez probablement un cas d'usage rentable. Le reste, c'est de l'exécution. --- ## Automatiser le service client avec un agent IA URL: https://algomax.fr/blog/automatiser-service-client-agent-ia Publié le : 2026-02-23 Description : Comment un agent IA peut traiter 80% des tickets support automatiquement, réduire vos coûts de 60% et libérer votre équipe des questions répétitives. # Automatiser le service client avec un agent IA Votre équipe support répond aux mêmes 50 questions par jour. Vous le savez. Eux aussi. "Où est ma commande ?", "Comment modifier mon adresse ?", "Je n'arrive pas à me connecter." Trois agents mobilisés à plein temps pour des réponses qui tiennent en deux phrases. Pendant ce temps, les vrais problèmes — ceux qui demandent de la réflexion, de l'empathie, une décision — attendent en file. Chez Algomax, on a déployé des agents IA de support client pour plusieurs entreprises B2B et e-commerce. On ne va pas vous dire que c'est magique. Mais les chiffres parlent d'eux-mêmes. ## Le coût réel d'un support client manuel Prenons un cas typique. Une entreprise e-commerce, 200 commandes par jour, trois agents support à temps plein. | Métrique | Avant (manuel) | |---|---| | Agents support | 3 | | Tickets par jour | 150 | | Temps moyen par ticket | 8 minutes | | Coût annuel (salaires + outils) | ~120 000 EUR | | Taux de satisfaction | 72% | | Temps d'attente moyen | 12 minutes | Les agents sont compétents. Le problème, c'est qu'ils passent 80% de leur temps sur des questions dont la réponse existe déjà dans la FAQ, les conditions de livraison ou la page "Mon compte". C'est du gaspillage. Pas de leur talent — de votre budget. ## Ce que change un agent IA Imaginons cette même entreprise après le déploiement d'un agent IA. | Métrique | Avant | Après | |---|---|---| | Agents humains | 3 | 1 (escalade uniquement) | | Tickets traités par IA | 0% | 80% | | Temps moyen par ticket | 8 min | 30 secondes (IA) / 10 min (humain) | | Coût annuel | ~120 000 EUR | ~50 000 EUR | | Taux de satisfaction | 72% | 85% | | Temps d'attente | 12 min | < 5 secondes (IA) | La satisfaction monte parce que les clients obtiennent une réponse immédiate à 2h du matin. Et l'agent humain restant se concentre sur les cas complexes — ce qui améliore aussi la qualité de ces interactions. On économise 70 000 EUR par an. Pas en théorie. En pratique, sur des déploiements réels. ## Comment ça fonctionne (sans jargon inutile) Un agent IA de support client repose sur trois briques techniques. Pas besoin d'un doctorat pour comprendre le principe. ### 1. RAG : la mémoire de votre entreprise RAG signifie Retrieval-Augmented Generation. En clair : l'agent IA cherche la bonne information dans votre base de connaissances avant de répondre. Vos FAQ, guides produits, conditions générales, procédures internes — tout est indexé. Quand un client pose une question, l'agent ne "devine" pas la réponse. Il la retrouve dans vos documents, puis la reformule de manière naturelle. C'est la différence entre un chatbot à mots-clés (celui qui répond "Je n'ai pas compris votre question" une fois sur deux) et un agent qui comprend réellement l'intention du client. Chez nous, on utilise des embeddings vectoriels pour indexer vos contenus. Le résultat : l'agent retrouve l'information pertinente même quand le client formule sa question de travers. "Mon colis est paumé" et "Statut de ma livraison" pointent vers la même réponse. ### 2. Tool use : agir, pas juste parler Un agent IA qui ne fait que répondre des textes a une utilité limitée. La vraie valeur arrive quand il peut agir. Grâce au mécanisme de tool use (appel d'outils), l'agent peut : - **Consulter le statut d'une commande** dans votre ERP ou CRM - **Modifier une adresse de livraison** directement dans le système - **Émettre un avoir ou un remboursement** selon vos règles métier - **Créer un ticket d'escalade** quand le problème dépasse ses compétences L'agent ne bidouille pas dans votre base de données. Il appelle des API que vous contrôlez, avec des permissions que vous définissez. Il peut consulter une commande mais pas supprimer un compte. Vous gardez le contrôle. ### 3. Escalade humaine : savoir passer la main C'est le point que beaucoup de vendeurs d'IA oublient de mentionner. Nous, on le met en avant. L'agent IA doit savoir quand il ne sait pas. Un client furieux après trois livraisons ratées ne veut pas parler à un robot. Un litige juridique ne se règle pas avec un modèle de langage. Une demande ambiguë mérite parfois un humain. Notre approche : l'agent IA détecte les signaux d'escalade (sentiment négatif, demande complexe, sujet sensible) et transfère la conversation à un agent humain avec tout le contexte. Le client ne répète pas son problème. L'agent humain voit l'historique complet. En pratique, 15 à 20% des conversations nécessitent une escalade. Ce ratio baisse avec le temps, à mesure que la base de connaissances s'enrichit. ## Intégrations concrètes Un agent IA qui ne se branche pas sur vos outils existants n'a aucun intérêt. Nous déployons sur les plateformes que vos équipes utilisent déjà. **Plateformes de support :** - Zendesk — intégration native via API, l'agent répond directement dans les tickets - Intercom — prise en charge des conversations en temps réel - Crisp — chat en direct avec basculement IA/humain **Canaux de communication :** - Email — analyse et réponse automatique aux emails entrants - WhatsApp Business — réponses instantanées sur le canal préféré de vos clients - Chat web — widget intégré à votre site **Systèmes métier :** - CRM (HubSpot, Salesforce) — consultation et mise à jour des fiches client - ERP / OMS — suivi de commandes, stocks, livraisons - Outils internes — via API REST, on connecte à peu près tout Le déploiement prend entre 2 et 4 semaines selon la complexité de vos processus et le volume de documentation à indexer. ## Scénario complet : l'e-commerçant qui dort enfin la nuit Imaginons une entreprise e-commerce avec 200 commandes par jour. Secteur : mode. Clientèle : particuliers, panier moyen 85 EUR. **Lundi, 23h47.** Une cliente écrit sur le chat : "J'ai commandé une robe taille M mais je voulais une S, c'est possible de changer ?" L'agent IA identifie l'intention (modification de commande), vérifie le statut de la commande via l'API du OMS. La commande n'est pas encore expédiée. Il vérifie la disponibilité de la taille S. Disponible. En 30 secondes, l'agent propose : "Votre commande #4821 n'est pas encore partie. Je peux modifier la taille de M à S. Souhaitez-vous que je procède ?" La cliente confirme. Modification faite. Confirmation envoyée par email. **Mardi, 14h20.** Un client écrit : "Ça fait 10 jours, toujours pas reçu ma commande, c'est une honte." Le ton est agressif. L'agent IA consulte le suivi : le colis est bloqué chez le transporteur depuis 5 jours. L'agent détecte le sentiment négatif et la complexité du problème (litige transporteur). Il répond : "Je comprends votre frustration. Votre colis est actuellement retenu chez le transporteur. Je transfère votre dossier à notre équipe pour un suivi prioritaire." Escalade immédiate avec tout le contexte. L'agent humain prend le relais en moins de 3 minutes. C'est ça, un agent IA bien calibré. Pas un remplacement total de l'humain. Un filtre intelligent qui traite le volume et protège l'humain pour les moments qui comptent. ## Ce qu'on ne vous dit pas (et qu'il faut savoir) On préfère être honnêtes. Voici les limites réelles. **L'agent se trompe parfois.** Sur 100 réponses, comptez 3 à 5 erreurs au début. Mauvaise interprétation, information obsolète dans la base de connaissances, cas limite non prévu. Le taux descend sous 2% après un mois de supervision et d'ajustements. Il ne sera jamais à zéro. **Les clients énervés veulent un humain.** On a beau optimiser le ton de l'agent, un client vraiment en colère ressent le chatbot comme un mur. L'escalade rapide est non négociable. Essayer de forcer l'IA sur ces cas détruit la satisfaction. **La base de connaissances demande de l'entretien.** Vos produits changent, vos procédures évoluent, vos conditions de livraison bougent. Si la base n'est pas à jour, l'agent donne des réponses fausses avec une confiance absolue. Prévoyez une revue mensuelle minimum. **Le déploiement n'est pas plug-and-play.** Il faut cartographier vos processus, rédiger les règles d'escalade, connecter vos API, tester sur des cas réels. Comptez 2 à 4 semaines de travail. C'est un investissement, pas un abonnement qu'on active en un clic. **La supervision reste nécessaire.** Même après le déploiement, quelqu'un doit surveiller les conversations, identifier les nouvelles questions non couvertes, ajuster les règles. Pas à plein temps — quelques heures par semaine suffisent. Mais ce n'est pas zéro. ## Les vrais gains, au-delà des économies Le chiffre de 70 000 EUR d'économie est parlant. Mais les gains les moins visibles sont parfois les plus importants. **Disponibilité 24/7.** Vos clients commandent le dimanche soir. Ils veulent une réponse le dimanche soir. Pas lundi matin. **Cohérence des réponses.** L'agent IA donne la même réponse à la même question, à chaque fois. Pas de variation selon l'humeur ou le niveau d'expérience de l'agent. **Données exploitables.** Chaque conversation est analysée. Vous savez exactement quelles questions reviennent, quels produits posent problème, quels points de friction existent dans votre parcours client. C'est de l'intelligence business gratuite. **Moral de l'équipe.** L'agent humain restant ne passe plus sa journée à copier-coller des réponses standards. Il traite des vrais problèmes. C'est plus intéressant, moins usant, et ça se voit sur le turnover. ## Passer à l'action Si votre équipe support traite plus de 50 tickets par jour et que vous reconnaissez votre situation dans cet article, le retour sur investissement d'un agent IA est quasiment garanti. Nous avons conçu notre [service d'agent IA pour le support client](/services/agent-ia-service-client) précisément pour ce cas d'usage. Le processus est structuré : audit de vos flux, déploiement progressif, supervision du premier mois. Si vous débutez avec l'IA en entreprise et souhaitez comprendre le cadre général avant de vous lancer, notre [guide pratique sur les agents IA pour entreprise](/blog/agent-ia-pour-entreprise-guide-pratique) couvre les fondamentaux. Le support client est souvent le premier domaine où l'IA apporte un ROI mesurable. Pas parce que c'est simple — parce que le volume de questions répétitives rend l'automatisation évidente. Commencez par là. Mesurez. Puis étendez. --- ## Combien coûte un agent IA en 2026 ? URL: https://algomax.fr/blog/combien-coute-un-agent-ia-en-2026 Publié le : 2026-02-23 Description : Prix réels, grilles tarifaires et coûts cachés d'un agent IA pour entreprise. Comparaison avec un employé, calcul de ROI et conseils pour éviter les mauvaises surprises. # Combien coûte un agent IA en 2026 ? Vous avez reçu trois devis. Le premier annonce 2 000 euros. Le deuxième, 15 000. Le troisième ne donne pas de prix sans un "audit préalable de 3 semaines". Bienvenue dans le marché des agents IA en 2026. Le problème n'est pas qu'il n'y a pas de prix. C'est que personne ne vous explique ce qui justifie l'écart. Chez Algomax, on livre des agents IA à des PME et des ETI depuis suffisamment longtemps pour savoir une chose : le budget n'est jamais le vrai frein. C'est l'incertitude sur ce que vous payez, et ce que ça rapporte. Cet article pose les chiffres sur la table. Sans arrondir vers le haut pour se laisser de la marge, sans minimiser les coûts récurrents. ## Ce qui fait varier le prix d'un agent IA Quatre facteurs déterminent 90 % du budget final. ### 1. La complexité des tâches Un agent qui répond à des questions fréquentes à partir d'une FAQ, ce n'est pas le même projet qu'un agent qui consulte votre CRM, vérifie un stock en temps réel, génère un devis et l'envoie par email. Le premier nécessite un prompt bien construit et une base de connaissances. Le second demande des intégrations, de la logique métier, et une gestion d'erreurs solide. Plus l'agent doit prendre de décisions, plus le coût monte. ### 2. Les intégrations Chaque système externe connecté ajoute du travail. Un branchement sur votre CRM (HubSpot, Salesforce, Pipedrive) prend entre 2 et 5 jours selon la qualité de l'API. Un ERP maison avec une API non documentée ? Comptez le double ou le triple. Les intégrations représentent souvent 30 à 50 % du budget total d'un agent. C'est le poste que les devis bas oublient systématiquement. ### 3. Le volume de conversations Un agent qui traite 50 conversations par mois et un agent qui en traite 5 000, ce n'est pas le même dimensionnement. Le coût des appels LLM (GPT-4, Claude, Mistral) est directement proportionnel au volume. Et au-delà d'un certain seuil, il faut optimiser les prompts, mettre en cache les réponses fréquentes, parfois utiliser des modèles plus légers pour les requêtes simples. ### 4. La maintenance dans le temps Un agent n'est pas un site web qu'on livre et qu'on oublie. Les modèles évoluent, vos produits changent, les cas limites apparaissent après la mise en production. La maintenance représente un coût récurrent qu'il faut intégrer dès le départ. ## Grille tarifaire : du chatbot simple à l'agent sur-mesure Voici ce que nous observons sur le marché en 2026, confirmé par nos propres projets. ### Chatbot simple — 1 000 à 5 000 euros Ce qu'il fait : répondre aux questions fréquentes à partir d'une base de connaissances statique. Pas d'intégration externe, pas de logique métier. Un widget sur votre site, connecté à vos FAQ ou votre documentation. Convient à : un site e-commerce qui veut décharger son support des questions sur les délais de livraison et la politique de retour. Limites : dès que la question sort du périmètre, l'agent est perdu. Pas de personnalisation par client, pas d'actions (prise de rendez-vous, modification de commande). ### Agent basique — 3 000 à 6 000 euros Ce qu'il fait : en plus de répondre aux questions, il se connecte à un ou deux outils (CRM, base de données produits) pour personnaliser ses réponses. Il peut qualifier un lead, orienter vers le bon interlocuteur, collecter des informations structurées. Convient à : une entreprise B2B qui veut automatiser la qualification de ses demandes entrantes. C'est notre offre Starter chez Algomax, à partir de 3 000 euros. On livre en 2 à 3 semaines. ### Agent complexe multi-outils — 6 000 à 12 000 euros Ce qu'il fait : il orchestre plusieurs outils. Il consulte votre CRM, vérifie la disponibilité dans votre ERP, génère un document, envoie un email, planifie un rendez-vous. Il gère des workflows en plusieurs étapes avec des conditions. Convient à : une PME ou ETI qui veut automatiser un processus métier complet (support client, onboarding, gestion de commandes). C'est notre offre Pro, à partir de 6 000 euros. Délai : 4 à 6 semaines selon le nombre d'intégrations. ### Agent sur-mesure — 12 000 euros et plus Ce qu'il fait : tout ce qui précède, plus des besoins spécifiques. Multi-langues, conformité réglementaire, intégration avec des systèmes legacy, logique métier complexe, déploiement on-premise. Convient à : une ETI ou un grand compte avec des contraintes fortes. Notre offre Enterprise démarre à 12 000 euros. Le prix dépend du périmètre. On cadre tout en amont pour éviter les surprises. ## Comparaison avec un employé Le calcul que tout le monde fait, et qu'il faut faire honnêtement. Un poste de support client ou d'assistant commercial en France coûte entre 35 000 et 45 000 euros par an, charges comprises. Ce collaborateur travaille 7 à 8 heures par jour, 220 jours par an. Il gère un volume limité de demandes, prend des congés, a besoin de formation. Un agent IA coûte entre 3 000 et 12 000 euros à la mise en place, puis 100 à 400 euros par mois en fonctionnement. Il est disponible 24h/24, 7j/7. Il traite des dizaines de conversations en parallèle. Mais soyons clairs : l'agent ne remplace pas un humain. Il remplace les tâches répétitives qu'un humain fait sans y trouver de valeur. La bonne approche, c'est de libérer vos équipes pour qu'elles se concentrent sur les cas qui nécessitent du jugement, de l'empathie, de la négociation. L'agent prend le reste. Sur un poste support qui passe 60 % de son temps sur des questions récurrentes, l'agent absorbe cette charge. Vous ne supprimez pas le poste — vous le rendez deux fois plus productif. ## Les coûts récurrents à prévoir Le prix initial ne représente qu'une partie du budget. Voici ce qui suit. **Hébergement et infrastructure** : entre 50 et 200 euros par mois selon le volume et l'architecture. Un agent léger sur une infrastructure serverless coûte moins qu'un agent avec des bases vectorielles et du traitement lourd. **Appels API aux modèles de langage** : c'est le poste le plus variable. Pour un agent qui traite 1 000 conversations par mois avec des échanges moyens de 5 messages, comptez entre 30 et 150 euros par mois selon le modèle utilisé. GPT-4o et Claude sont plus chers que Mistral ou des modèles open-source, mais souvent plus fiables sur des tâches complexes. **Mises à jour et évolutions** : vos produits changent, vos processus évoluent, de nouveaux cas d'usage apparaissent. Prévoyez entre 500 et 1 500 euros par trimestre pour les ajustements. Chez Algomax, nos offres Pro et Enterprise incluent un forfait de maintenance. **Monitoring** : un agent en production doit être surveillé. Les réponses incorrectes, les conversations abandonnées, les erreurs d'intégration — tout cela doit être détecté et corrigé. Le monitoring peut être inclus dans la maintenance ou facturé séparément. ## Calcul de ROI concret Prenons un cas réel simplifié. Une PME reçoit 800 demandes de support par mois. Chaque demande prend en moyenne 12 minutes à traiter par un humain. Coût interne estimé : 2 équivalents temps plein, soit environ 75 000 euros par an. On déploie un agent IA (offre Pro à 6 000 euros) qui prend en charge 65 % des demandes — celles qui sont récurrentes et bien documentées. L'agent coûte environ 250 euros par mois en fonctionnement (hébergement + API + maintenance lissée). **Investissement année 1** : 6 000 + (250 x 12) = 9 000 euros. **Économie** : 65 % de 75 000 euros = 48 750 euros. Même en étant conservateur et en comptant 50 % d'économie effective (parce que les humains libérés sont réaffectés, pas licenciés), vous dégagez 28 000 euros de valeur la première année. **ROI année 1** : environ 3x l'investissement. Année 2 et suivantes, le ROI s'améliore puisque le coût initial est amorti. ## Les coûts cachés que tout le monde oublie Quelques postes que les devis ne mentionnent pas toujours. **La préparation des données d'entraînement.** Si votre documentation est éparpillée dans 15 Google Docs, 3 PDF et la tête de votre meilleur technicien, il faut d'abord structurer tout ça. Ce travail est souvent sous-estimé. Comptez 1 à 3 jours de travail côté client. **Les cas limites.** Un agent gère bien 80 % des cas dès le lancement. Les 15 % suivants demandent des ajustements dans les semaines qui suivent. Les 5 % restants sont parfois impossibles à automatiser. Il faut accepter cette réalité et prévoir le budget d'ajustement. **Le temps interne.** Vos équipes doivent participer : définir les cas d'usage, valider les réponses, tester l'agent avant la mise en production. Ce n'est pas un projet qu'on sous-traite entièrement sans implication. **Le coût de l'escalade.** Quand l'agent ne sait pas répondre, il doit transmettre à un humain. Ce mécanisme d'escalade doit être conçu, intégré, et testé. C'est rarement gratuit. ## Quand ne pas investir dans un agent IA On ne va pas vous dire que tout le monde a besoin d'un agent. Ce serait malhonnête. **Volume trop faible.** Si vous recevez 20 demandes par mois, un agent IA ne se justifie pas économiquement. Un bon formulaire structuré et des réponses templates feront l'affaire. **Cas exclusivement complexes.** Si 90 % de vos demandes nécessitent un jugement humain (négociation contractuelle, diagnostic technique poussé, gestion de crise), l'agent n'apportera pas grand-chose. Il faut un volume suffisant de tâches répétitives pour que l'investissement ait du sens. **Données inexistantes.** Un agent a besoin de contenu pour fonctionner. Si vous n'avez aucune documentation, aucune FAQ, aucun historique de conversations, le premier investissement doit aller dans la structuration de vos connaissances, pas dans un agent. **Absence de sponsor interne.** Un projet d'agent IA qui n'a pas de porteur côté client échoue dans 80 % des cas. Si personne dans votre équipe ne prend la responsabilité de tester, ajuster et promouvoir l'outil en interne, ne lancez pas le projet. ## Ce que vous payez chez Algomax On croit à la transparence tarifaire. Voici nos trois offres. | Offre | Prix | Inclus | Délai | |---|---|---|---| | **Starter** | 3 000 euros | Agent conversationnel, 1-2 intégrations, déploiement, 1 mois de support | 2-3 semaines | | **Pro** | 6 000 euros | Agent multi-outils, jusqu'à 5 intégrations, workflows, maintenance trimestrielle | 4-6 semaines | | **Enterprise** | 12 000 euros+ | Sur-mesure, intégrations illimitées, conformité, SLA, maintenance continue | 6-10 semaines | Les prix incluent la conception, le développement, les tests et la mise en production. L'hébergement et les coûts d'API sont facturés séparément au réel. Vous voulez un chiffrage précis pour votre cas ? [Consultez notre page tarifs](/services/prix-agent-ia) ou contactez-nous directement. Et si vous hésitez encore entre un chatbot classique et un véritable agent IA, on a écrit un article qui clarifie la différence : [Chatbot IA vs Agent IA : quelle différence ?](/blog/chatbot-ia-vs-agent-ia-quelle-difference) ## Le bon réflexe avant de signer Demandez toujours un devis détaillé avec les postes suivants : développement initial, intégrations (listées une par une), hébergement mensuel, estimation des coûts API, maintenance, et conditions de modification post-livraison. Si un prestataire ne peut pas vous fournir cette ventilation, c'est un signal. Soit il ne maîtrise pas ses coûts, soit il préfère que vous ne les connaissiez pas. Un agent IA bien cadré, bien déployé et bien maintenu est un des meilleurs investissements qu'une entreprise puisse faire en 2026. Mais comme tout investissement, il doit être dimensionné par rapport à un besoin réel, pas par rapport à une tendance. --- ## React Native vs Natif : guide pour décideurs non-techniques URL: https://algomax.fr/blog/react-native-vs-natif-guide-pour-decideurs-non-techniques Publié le : 2026-02-23 Description : Vous hésitez entre React Native et le développement natif pour votre app ? Ce guide sans jargon vous aide à faire le bon choix selon votre budget, vos délais et vos besoins. # React Native vs Natif : guide pour décideurs non-techniques Vous voulez créer une application mobile. Votre prestataire vous pose la question : "Natif ou React Native ?" Vous hochez la tête, vous notez les deux mots, et vous allez chercher sur Google ce que ça signifie. Vous n'êtes pas le seul. C'est la question la plus fréquente que posent les fondateurs et les dirigeants d'entreprise quand ils lancent un projet mobile. Et c'est normal : cette décision a un impact direct sur votre budget, vos délais et la qualité de votre application. Le problème, c'est que la plupart des articles sur le sujet sont écrits par des développeurs, pour des développeurs. Plein de termes techniques, d'opinions tranchées et de débats stériles. Cet article est écrit pour vous, le décideur qui doit faire un choix éclairé sans devenir ingénieur. ## La différence, en termes simples Imaginez que vous voulez construire deux maisons identiques : une à Paris et une à Lyon. ### L'approche native, c'est deux chantiers séparés Vous engagez une équipe à Paris qui construit avec les matériaux et les méthodes parisiennes. Et une autre équipe à Lyon qui construit avec les matériaux et les méthodes lyonnaises. Les deux maisons sont parfaitement adaptées à leur environnement local. Mais vous payez deux architectes, deux équipes, deux chantiers. En développement mobile, c'est pareil. L'approche native signifie : - Une application iOS développée en **Swift** (le langage d'Apple) - Une application Android développée en **Kotlin** (le langage de Google) - Deux bases de code séparées, deux équipes (ou une équipe qui fait les deux, mais séquentiellement) ### React Native, c'est un seul plan d'architecte Vous dessinez un seul plan. Ensuite, sur chaque chantier, ce plan est adapté aux spécificités locales. Vous n'avez qu'un architecte, qu'un plan, mais vous obtenez deux maisons fonctionnelles. En développement mobile : - **Une seule base de code** écrite en JavaScript/TypeScript (des langages de programmation très répandus) - Cette base de code génère une application iOS et une application Android - L'application utilise les composants natifs de chaque système (ce n'est pas un site web déguisé en application) C'est important de le comprendre : React Native produit de vraies applications natives. Les boutons, les animations, les interactions : tout utilise les composants du système. L'utilisateur ne voit pas la différence. ## Tableau comparatif | Critère | React Native | Natif (Swift + Kotlin) | |---|---|---| | **Nombre de bases de code** | 1 | 2 | | **Budget iOS + Android** | Base | 1,5x à 2x | | **Délai de développement** | 4-12 semaines | 8-20 semaines | | **Performance** | Excellente (95 % des cas) | Maximale | | **Accès aux fonctions du téléphone** | Complet (via des modules complémentaires) | Direct et complet | | **Maintenance** | Une seule app à maintenir | Deux apps à maintenir | | **Profil développeur** | Un développeur React Native | Un dev iOS + un dev Android | | **Mises à jour** | Simultanées sur les deux plateformes | À faire deux fois | | **Applications qui l'utilisent** | Instagram, Airbnb, Discord, Shopify | Toutes les apps Apple et Google | ## Quand choisir React Native React Native est le bon choix dans la grande majorité des projets d'entreprise. Voici les situations où il excelle. ### Vous voulez être sur iOS et Android Si vos utilisateurs sont répartis entre iPhone et Android (et en France, c'est environ 30 % iOS et 70 % Android), vous avez besoin des deux plateformes. React Native vous fait économiser 30 à 40 % par rapport à deux développements natifs. ### Votre budget est limité Entre 15 000 euros pour une application React Native et 25 000 à 30 000 euros pour deux applications natives, la différence finance des fonctionnalités supplémentaires ou une meilleure campagne de lancement. ### Vous voulez aller vite Un seul développement au lieu de deux, c'est un calendrier divisé par 1,5 en moyenne. Si le time-to-market est critique pour votre projet, React Native vous donne un avantage. ### Votre application est centrée sur du contenu et des interactions classiques Formulaires, listes, cartes, profils, messagerie, paiement, notifications, géolocalisation. React Native gère tout cela parfaitement. C'est le quotidien de 90 % des applications d'entreprise. ### Vous prévoyez des évolutions fréquentes Une seule base de code signifie une seule mise à jour quand vous ajoutez une fonctionnalité ou corrigez un bug. Vos deux plateformes évoluent en même temps, sans décalage. ## Quand choisir le natif Le développement natif reste pertinent dans certains cas spécifiques. ### Votre application a des besoins graphiques très poussés Jeux 3D, réalité augmentée avancée, animations complexes à 60 images par seconde. Le natif offre un contrôle total sur le rendu graphique. Si votre application est un jeu ou utilise la réalité augmentée de manière intensive, le natif est préférable. ### Vous exploitez des fonctions hardware très spécifiques Bluetooth Low Energy avec des protocoles propriétaires, NFC avancé, traitement audio en temps réel, accès aux capteurs biométriques avancés. Certaines fonctions hardware très spécialisées sont mieux supportées en natif. Attention : la plupart des fonctions courantes (caméra, GPS, notifications push, paiement) fonctionnent parfaitement avec React Native. Ce sont les cas extrêmes qui justifient le natif. ### Vous ciblez une seule plateforme Si votre application est exclusivement pour iPhone (par exemple une app interne pour une entreprise qui équipe tout le monde en iPhone), le développement en Swift seul peut être pertinent. Vous éliminez l'étape intermédiaire de traduction sans en payer le prix puisque vous n'avez qu'une plateforme à gérer. ### La performance absolue est critique Pour des applications de trading haute fréquence, de traitement vidéo en temps réel ou de contrôle d'appareils médicaux, chaque milliseconde compte. Le natif élimine toute couche intermédiaire. Mais soyons honnêtes : moins de 5 % des projets d'entreprise tombent dans cette catégorie. ## Comparaison des coûts Mettons des chiffres concrets pour un projet type : une application de gestion de rendez-vous avec espace client, notifications push, paiement en ligne et un petit tableau de bord. ### Avec React Native | Poste | Budget | |---|---| | Design UI/UX | 3 000 - 5 000 € | | Développement (iOS + Android) | 10 000 - 18 000 € | | Back-end et API | 4 000 - 8 000 € | | Tests et déploiement | 1 500 - 3 000 € | | **Total** | **18 500 - 34 000 €** | Maintenance mensuelle : 300 - 800 euros. ### En natif (Swift + Kotlin) | Poste | Budget | |---|---| | Design UI/UX | 3 000 - 5 000 € | | Développement iOS (Swift) | 10 000 - 18 000 € | | Développement Android (Kotlin) | 10 000 - 18 000 € | | Back-end et API | 4 000 - 8 000 € | | Tests et déploiement (x2) | 2 500 - 5 000 € | | **Total** | **29 500 - 54 000 €** | Maintenance mensuelle : 500 - 1 200 euros (deux bases de code). L'écart est significatif : 35 à 40 % d'économie avec React Native, sans sacrifice notable sur la qualité. Et cet écart se creuse dans le temps avec la maintenance. ## Les mythes qu'il faut oublier ### "React Native, c'est moins bien que le natif" C'était vrai en 2018. Ce ne l'est plus en 2026. React Native a été entièrement réécrit (architecture "New Architecture") et ses performances sont proches du natif dans la quasi-totalité des cas. Instagram, Discord, Shopify, Microsoft. Ces entreprises l'utilisent en production pour des centaines de millions d'utilisateurs. ### "Les utilisateurs voient la différence" Non. Une application React Native bien développée est indistinguable d'une application native pour l'utilisateur final. Les animations sont fluides, les interactions réactives, l'expérience cohérente avec les conventions de chaque plateforme. ### "On ne peut pas faire d'IA avec React Native" Faux. L'intelligence artificielle dans une application mobile repose principalement sur des appels à des API (modèles de langage, vision, voix). React Native gère ces appels exactement comme le natif. Chez Algomax, nous intégrons régulièrement des fonctionnalités IA dans nos applications React Native. ### "React Native, c'est pour les petits projets" Facebook (aujourd'hui Meta) a créé React Native pour ses propres applications. Walmart, Bloomberg, Pinterest l'utilisent. Ce n'est pas un outil pour les "petits budgets". C'est un choix technique intelligent pour la plupart des projets. ## La recommandation Algomax Chez Algomax, nous développons en React Native pour 90 % de nos projets d'application mobile. Voici pourquoi. **Le rapport qualité/prix est imbattable.** Nos clients obtiennent une application sur les deux plateformes pour le prix d'une seule. Le budget économisé finance des fonctionnalités supplémentaires, de l'IA intégrée ou un lancement mieux préparé. **La vitesse de livraison.** Nous livrons des MVP en 4 à 8 semaines. Impossible avec un double développement natif. **La maintenabilité.** Une seule base de code, c'est moins de bugs, des mises à jour plus rapides et un coût de maintenance divisé par deux. **La flexibilité.** Si une fonctionnalité spécifique nécessite du code natif, React Native le permet. On peut écrire un module en Swift ou en Kotlin et l'intégrer dans l'application React Native. Le meilleur des deux mondes. Nous ne recommandons le développement natif que dans les rares cas où c'est techniquement justifié : applications à forte composante graphique 3D, réalité augmentée avancée, ou contraintes hardware très spécifiques. [Découvrez notre offre de développement d'applications mobiles](/services/application-mobile). ## Comment prendre votre décision Posez-vous ces quatre questions : **1. Votre application a-t-elle besoin d'être sur iOS et Android ?** Si oui, React Native. L'économie est trop significative pour l'ignorer. **2. Votre application est-elle un jeu ou utilise-t-elle massivement la 3D ?** Si oui, natif (ou un moteur de jeu comme Unity). Sinon, React Native. **3. Avez-vous besoin de fonctions hardware très spécialisées ?** Si c'est du Bluetooth propriétaire, du NFC avancé ou du traitement audio temps réel, explorez le natif. Si c'est de la caméra, du GPS, du push, React Native gère sans problème. **4. Votre budget est-il contraint ?** Si vous devez choisir entre "une bonne app React Native" et "une app native à moitié finie", le choix est vite fait. Dans 9 cas sur 10, la réponse sera React Native. Et dans le dixième cas, un bon développeur React Native saura vous le dire honnêtement. ## Prêt à lancer votre application ? Vous avez maintenant les éléments pour prendre une décision éclairée. Pas besoin de comprendre le code. Il suffit de comprendre votre besoin, votre budget et vos contraintes. Chez Algomax, nous accompagnons les fondateurs et les dirigeants d'entreprise de A à Z : du cadrage à la mise en production, en passant par le design, le développement et le déploiement sur les stores. Et si votre application intègre de l'intelligence artificielle, nous savons faire aussi. [Découvrez nos applications mobiles avec IA intégrée](/services/application-mobile-ia). Pour comprendre le budget global de votre projet, consultez notre guide : [Combien coûte une application mobile en 2026 ?](/blog/combien-coute-application-mobile-2026) --- ## Pourquoi choisir une agence IA locale à Strasbourg ? URL: https://algomax.fr/blog/pourquoi-choisir-une-agence-ia-locale-a-strasbourg Publié le : 2026-02-22 Description : Les avantages de travailler avec une agence IA basée à Strasbourg. Proximité, réactivité, compréhension du marché français. Guide pour choisir votre partenaire IA en Alsace. # Pourquoi choisir une agence IA locale à Strasbourg ? Vous cherchez un prestataire pour votre projet d'intelligence artificielle. Votre boîte de réception déborde de propositions : agences parisiennes, freelances à Lisbonne, équipes offshore en Inde, startups en remote total. Tout le monde promet la même chose. Les prix varient du simple au quintuple. Et si la meilleure option était plus proche que vous ne le pensez ? Strasbourg est devenue en quelques années un pôle technologique reconnu en France et en Europe. La ville attire des talents, des startups et des entreprises qui investissent dans l'IA. Travailler avec une agence locale, ce n'est pas un choix par défaut. C'est un choix calculé. Voici pourquoi. ## La proximité change tout dans un projet IA Un projet d'intelligence artificielle n'est pas un site vitrine. C'est un projet qui touche à vos données, vos processus métier, vos clients. Il nécessite une compréhension fine de votre activité, des allers-retours fréquents, et une confiance mutuelle. ### Les réunions en personne font gagner du temps On peut tout faire en visio. Mais un atelier de cadrage de deux heures dans vos locaux, avec votre équipe, un tableau blanc et un café, produit des résultats qu'aucun appel Zoom ne peut égaler. Les non-dits remontent. Les cas limites apparaissent. Les priorités se clarifient. À Strasbourg, votre agence est à 20 minutes en voiture ou en tram. Pas à un vol intérieur et une nuit d'hôtel. ### La réactivité en cas de problème Un agent IA en production qui dysfonctionne un vendredi soir, c'est un problème qui ne peut pas attendre le lundi matin, et encore moins le décalage horaire d'une équipe à Bangalore. Une agence strasbourgeoise dans le même fuseau horaire, joignable par téléphone, qui connaît votre projet, c'est une assurance que vous apprécierez le jour où vous en aurez besoin. ### La connaissance de votre marché Une agence basée en Alsace comprend le tissu économique local. Les PME industrielles du Bas-Rhin et du Haut-Rhin. Les spécificités du commerce transfrontalier avec l'Allemagne et la Suisse. Les contraintes des entreprises qui travaillent à la fois en français et en allemand. Cette connaissance du contexte ne s'improvise pas. Elle se vit au quotidien. ## Strasbourg : un écosystème technologique en pleine croissance Strasbourg n'est pas qu'une ville de fonctionnaires européens. C'est un pôle d'innovation qui monte en puissance. ### Un vivier de talents techniques L'Université de Strasbourg et ses écoles d'ingénieurs (INSA Strasbourg, Télécom Physique Strasbourg, ECPM) forment chaque année des centaines de diplômés en informatique, data science et intelligence artificielle. Le CNRS et l'INSERM y mènent des recherches de pointe en IA appliquée à la santé et à l'industrie. Ce vivier de talents alimente un écosystème d'entreprises tech qui grandit d'année en année. ### Une position stratégique en Europe Strasbourg est au carrefour de la France, de l'Allemagne et de la Suisse. Le TGV met Paris à 1h46. Francfort est à 2 heures de route. Bâle à 1h30. Zurich à 2h30. Pour une entreprise alsacienne qui travaille avec des clients ou des fournisseurs dans ces pays, avoir une agence IA qui comprend le contexte transfrontalier est un atout majeur. Les enjeux de multilinguisme, de conformité multi-juridictionnelle, de traduction automatique. Ce sont des sujets que les agences strasbourgeoises maîtrisent naturellement. ### Un écosystème startup dynamique Le Shadok, la SEMIA, le Pôle Entrepreneuriat Étudiant de Strasbourg. La ville investit dans l'innovation. Le quartier numérique de la Presqu'île Malraux concentre de plus en plus d'entreprises tech. Des événements comme Strasbourg Startup Summit et les meetups IA attirent une communauté active. Cet écosystème crée un cercle vertueux : les agences IA locales ont accès aux dernières innovations, aux partenariats technologiques et aux talents formés sur place. ## Ce qu'il faut regarder avant de choisir une agence IA Que vous choisissiez une agence à Strasbourg ou ailleurs, voici les critères qui comptent vraiment. ### L'expertise technique réelle L'IA est un domaine vaste. Un prestataire qui dit "on fait de l'IA" sans préciser quoi, c'est comme un médecin qui dit "je soigne des gens" sans spécialité. Posez des questions précises : - Quels modèles de langage utilisez-vous et pourquoi ? - Comment gérez-vous la confidentialité des données ? - Quelles sont vos intégrations habituelles (CRM (gestion clients), ERP (gestion d'entreprise), outils métier) ? - Comment mesurez-vous la performance d'un agent IA en production ? Un bon prestataire répond sans hésiter, avec des exemples concrets. ### Les références dans votre secteur Un agent IA pour un cabinet d'avocats et un agent IA pour un e-commerce, ce sont deux projets radicalement différents. Demandez des références dans votre industrie ou dans des contextes similaires au vôtre. ### La transparence sur les prix Méfiez-vous des devis opaques. Un bon prestataire détaille : développement, intégrations, hébergement, coûts d'API, maintenance. [Notre article sur les prix des agents IA](/blog/combien-coute-un-agent-ia-en-2026) vous donne les repères pour évaluer un devis. ### La propriété du code et des données Vous devez rester propriétaire de tout ce qui est développé pour vous. Le code source, les données d'entraînement, les configurations, les prompts. Si le prestataire garde la main sur votre code, vous êtes prisonnier. ### La capacité d'accompagnement dans le temps Un agent IA n'est pas un projet one-shot. Il évolue, s'améliore, s'adapte à vos besoins changeants. Votre agence doit être un partenaire de long terme, pas un prestataire qui disparaît après la livraison. ## Les erreurs courantes quand on choisit un prestataire IA Quelques pièges que nous voyons régulièrement chez les entreprises de la région Grand Est. ### Choisir le moins cher Un devis à 1 500 euros pour un agent IA, c'est un chatbot basique branché sur une FAQ. Ce n'est pas un agent intelligent. Si votre besoin est simple, c'est peut-être suffisant. Mais si vous avez des intégrations métier, des cas d'usage complexes, des exigences de fiabilité, le prix reflète la qualité du travail. ### Confondre IA générative et IA tout court Tout le monde parle de ChatGPT. Mais l'IA dans votre entreprise, ce n'est pas forcément un chatbot. C'est peut-être de la classification automatique de documents. Ou de l'analyse prédictive. Ou de la vision par ordinateur. Un bon prestataire commence par comprendre votre problème, pas par vous vendre la technologie à la mode. ### Négliger la phase de cadrage Le cadrage représente 20 % du temps d'un projet mais détermine 80 % de sa réussite. Les entreprises qui veulent "aller vite" et sautent cette étape se retrouvent avec un agent qui ne correspond pas à leurs besoins, trois mois de retard et un budget dépassé. ### Ne pas impliquer les équipes métier Un projet IA piloté uniquement par la direction ou par le service informatique échoue presque systématiquement. Les utilisateurs finaux doivent être impliqués dès le début : ils connaissent les cas limites, les exceptions, les vrais besoins du terrain. ### Sous-estimer la maintenance Un agent IA en production, c'est un organisme vivant. Vos produits changent, vos processus évoluent, les modèles de langage se mettent à jour. Sans maintenance régulière, votre agent devient obsolète en quelques mois. ## Pourquoi Algomax Algomax est une agence spécialisée en intelligence artificielle et en développement d'applications, basée à Strasbourg. Ce qui nous distingue : **L'expertise combinée IA et développement.** Nous ne sommes pas des consultants qui théorisent sur l'IA. Nous écrivons le code, nous déployons les agents, nous maintenons les systèmes en production. Et nous développons aussi des [applications mobiles](/services/application-mobile) et des [applications web](/services/application-web), ce qui nous permet de proposer des solutions complètes. **La proximité.** Nous travaillons avec des entreprises en Alsace, dans le Grand Est et dans toute la France. Pour nos clients strasbourgeois, on se déplace dans vos locaux. Pour les autres, on combine visio et déplacements ponctuels. **La transparence.** Nos prix sont affichés. Nos méthodes sont expliquées. Vous savez ce que vous payez et pourquoi. Pas de boîte noire. **L'accompagnement dans la durée.** Nous ne livrons pas un agent et ne disparaissons pas. Nous proposons des contrats de maintenance, du monitoring en continu et des évolutions régulières. [Découvrez nos agents IA sur-mesure](/services/agent-ia-sur-mesure) ou [visitez notre page Strasbourg](/agence-strasbourg) pour en savoir plus sur notre ancrage local. ## Travailler avec une agence IA à Strasbourg : ce que ça donne en pratique Voici comment se déroule un projet type avec Algomax, du premier contact à la mise en production. **Semaine 1 : découverte.** On se rencontre dans vos locaux à Strasbourg ou dans notre bureau. On écoute. On pose des questions. On identifie le ou les cas d'usage à fort potentiel. **Semaines 2-3 : cadrage et maquettage.** On définit le périmètre précis, les intégrations nécessaires, les métriques de succès. Vous recevez un devis détaillé et un planning. **Semaines 4-8 : développement et itérations.** On développe, on vous montre des versions intermédiaires, on ajuste. Pas de surprise à la livraison. **Semaine 9 : mise en production et formation.** L'agent est déployé, vos équipes sont formées, le monitoring est en place. **Après : maintenance et évolution.** On surveille les performances, on corrige les cas limites, on fait évoluer l'agent avec vos besoins. ## Prêt à lancer votre projet IA à Strasbourg ? Que vous soyez une PME industrielle du Bas-Rhin, un commerce en centre-ville de Strasbourg, une startup du numérique ou une ETI du Grand Est, si vous avez un projet d'intelligence artificielle, on peut vous aider. Pas de jargon. Pas de promesse irréaliste. Un diagnostic honnête de ce que l'IA peut apporter à votre entreprise, et un plan clair pour y arriver. [Prenez contact avec nous](/agence-strasbourg) pour un premier échange sans engagement. On se retrouve autour d'un café. À Strasbourg, c'est facile. --- ## IA dans une application mobile : 7 cas d'usage concrets URL: https://algomax.fr/blog/ia-dans-une-application-mobile-7-cas-d-usage-concrets Publié le : 2026-02-21 Description : Découvrez 7 façons concrètes d'intégrer l'intelligence artificielle dans votre application mobile. Chatbot, recommandations, vision, vocal et plus. # IA dans une application mobile : 7 cas d'usage concrets L'intelligence artificielle dans une application mobile, ce n'est pas un gadget marketing. Elle permet d'améliorer l'expérience utilisateur et d'automatiser des tâches qui vous coûtent cher. Mais entre les promesses des éditeurs et la réalité du terrain, il y a un écart. Tout le monde parle d'IA. Peu de gens expliquent ce que ça fait concrètement dans une application mobile, combien ça coûte, et surtout si ça vaut le coup pour votre entreprise. Chez Algomax, nous intégrons l'IA dans des applications mobiles pour des PME et des ETI. Voici sept cas d'usage que nous avons déployés ou accompagnés, avec des exemples concrets et des indications de budget. ## 1. Chatbot embarqué : un support client disponible 24h/24 ### Ce que ça fait Un assistant conversationnel intégré directement dans votre application. L'utilisateur pose une question, le chatbot répond instantanément en se basant sur votre documentation, vos FAQ, vos données produit. Ce n'est pas le chatbot basique de 2020 qui répondait "Je n'ai pas compris votre question" une fois sur deux. Les modèles de langage actuels — les logiciels d'IA comme GPT-4, Claude ou Mistral — comprennent le contexte, gèrent les nuances et peuvent mener une conversation naturelle. ### Exemple concret Une application de gestion locative intègre un chatbot qui répond aux questions des locataires : état des lieux, délais de réparation, documents à fournir. Le chatbot consulte le dossier du locataire et personnalise ses réponses. Résultat : 70 % des demandes résolues sans intervention humaine. ### Budget indicatif 3 000 à 8 000 euros pour l'intégration initiale. 50 à 200 euros par mois en coûts d'API (requêtes envoyées aux services d'intelligence artificielle) selon le volume de conversations. ### Pour qui Toute entreprise dont l'application génère des questions récurrentes de la part des utilisateurs. E-commerce, services, santé, immobilier. ## 2. Recommandations personnalisées : chaque utilisateur voit ce qui l'intéresse ### Ce que ça fait L'application analyse le comportement de chaque utilisateur (ce qu'il consulte, ce qu'il achète, ce qu'il ignore) et lui propose du contenu ou des produits pertinents. Plus l'utilisateur interagit, plus les recommandations deviennent précises. C'est ce que font Netflix, Spotify et Amazon. La différence, c'est qu'en 2026, ces technologies sont accessibles à des entreprises de toute taille, pas seulement aux géants du web. ### Exemple concret Une application de formation professionnelle recommande des modules de cours en fonction du profil, du niveau et des objectifs de chaque apprenant. Le taux de complétion des formations passe de 35 % à 62 %. ### Budget indicatif 5 000 à 12 000 euros pour la mise en place. Les coûts récurrents dépendent du volume de données et de la complexité du modèle. ### Pour qui E-commerce, marketplaces, applications de contenu, plateformes de formation. Dès que vous avez un catalogue et des utilisateurs avec des préférences différentes. ## 3. Vision par ordinateur : votre application comprend les images ### Ce que ça fait L'application utilise la caméra du téléphone pour analyser ce qu'elle voit. Reconnaissance d'objets, scan de documents, détection de défauts, identification de produits. La vision par ordinateur transforme le smartphone en outil de travail intelligent. Plus besoin de saisir des informations manuellement. L'application les capture et les interprète. ### Exemple concret Une application pour artisans du bâtiment permet de photographier un compteur électrique. L'IA extrait automatiquement les relevés, les enregistre dans le dossier client et prépare le rapport d'intervention. Ce qui prenait 10 minutes de saisie se fait en 3 secondes. Un autre cas : une application de tri sélectif. L'utilisateur photographie un déchet, l'IA identifie le matériau et indique la poubelle correspondante. ### Budget indicatif 8 000 à 20 000 euros selon la complexité de la reconnaissance. Un scan de document simple est moins coûteux qu'une détection de défauts industriels en temps réel. ### Pour qui Industrie, logistique, BTP, santé, agriculture. Tout métier qui manipule des objets physiques et a besoin de les identifier, mesurer ou documenter. ## 4. Assistant vocal : votre application écoute et répond ### Ce que ça fait L'utilisateur parle à l'application au lieu de taper. L'IA transcrit la voix en texte, comprend l'intention, exécute l'action et répond, par écrit ou par la voix. Ce n'est pas un simple dictaphone. L'assistant vocal comprend le contexte. "Décale mon rendez-vous de demain à jeudi". Il sait quel rendez-vous, il connaît le calendrier, il propose un créneau. ### Exemple concret Une application pour commerciaux itinérants. Entre deux rendez-vous, le commercial dicte son compte-rendu. L'IA structure les notes, identifie les actions à suivre, met à jour le CRM (l'outil de gestion de la relation client). Le commercial gagne 45 minutes par jour. ### Budget indicatif 4 000 à 10 000 euros pour l'intégration. Les coûts de transcription vocale via des services comme Whisper ou Deepgram (des services de transcription vocale automatique) sont relativement faibles : 0,006 euro par minute de transcription environ. ### Pour qui Applications métier pour des utilisateurs mobiles (commerciaux, techniciens, livreurs). Applications d'accessibilité. Toute situation où les mains sont occupées. ## 5. Analytics prédictif : anticiper au lieu de réagir ### Ce que ça fait L'IA analyse les données historiques de votre application pour prédire des comportements futurs. Quels utilisateurs vont se désabonner ? Quels produits vont être en rupture ? À quel moment de la journée le trafic va augmenter ? Ce n'est pas de la boule de cristal. C'est de la statistique appliquée à vos données réelles. Et la prédiction n'a pas besoin d'être parfaite pour avoir de la valeur. Il suffit qu'elle soit meilleure que l'intuition seule. ### Exemple concret Une application en ligne destinée aux professionnels détecte les signaux de désengagement (baisse de connexions, fonctionnalités moins utilisées) et alerte automatiquement le customer success manager avant que le client ne résilie. Le taux de churn (le pourcentage de clients qui partent) baisse de 25 %. ### Budget indicatif 6 000 à 15 000 euros pour la mise en place. Nécessite un volume de données suffisant : au moins 6 mois d'historique et plusieurs centaines d'utilisateurs actifs. ### Pour qui Applications en ligne (SaaS), e-commerce, services par abonnement. Toute entreprise qui a des données d'usage et veut les exploiter pour prendre de meilleures décisions. ## 6. Génération de contenu : l'application crée pour l'utilisateur ### Ce que ça fait L'application génère du texte, des images ou des suggestions adaptées au contexte de l'utilisateur. Rédaction d'emails, création de descriptions produit, suggestions de légendes pour les réseaux sociaux, résumés automatiques. L'IA ne remplace pas la créativité humaine. Elle accélère la production et fournit un premier jet que l'utilisateur peut affiner. ### Exemple concret Une application pour agents immobiliers génère automatiquement les annonces à partir des caractéristiques du bien (surface, localisation, photos). L'agent ajuste le ton et publie en quelques minutes au lieu d'y consacrer une heure. ### Budget indicatif 3 000 à 8 000 euros pour l'intégration. Les coûts d'API dépendent du volume de contenu généré, mais restent modérés pour du texte (moins de 100 euros par mois pour un usage standard). ### Pour qui Applications de productivité, outils métier, marketplaces. Tout cas où l'utilisateur doit produire du contenu de manière répétitive. ## 7. Classification et tri automatique : l'application organise toute seule ### Ce que ça fait L'IA catégorise automatiquement les données entrantes. Emails classés par urgence et sujet. Tickets de support routés vers le bon service. Documents triés par type. Photos organisées par catégorie. C'est souvent le cas d'usage le plus simple à mettre en place et celui qui a le meilleur rapport effort/résultat. ### Exemple concret Une application de gestion de sinistres pour un courtier en assurances. Le client envoie des photos et des documents. L'IA identifie le type de sinistre (dégât des eaux, accident auto, vol), classe les documents (constat, facture, photo) et pré-remplit le dossier. Le courtier ne fait plus que valider et transmettre. ### Budget indicatif 3 000 à 7 000 euros pour la mise en place. Coûts récurrents faibles si le volume de classification reste raisonnable. ### Pour qui Assurances, banques, cabinets comptables, services RH. Tout métier qui passe du temps à trier, classer et router des informations. ## Comment choisir le bon cas d'usage pour votre application Ne partez pas de la technologie. Partez du problème. **Identifiez les tâches répétitives.** Où vos utilisateurs ou vos équipes perdent-ils du temps ? Quelles actions sont toujours les mêmes, avec de légères variations ? **Mesurez le volume.** L'IA a besoin de volume pour se justifier économiquement. 10 classifications par jour, c'est trop peu. 200, c'est le bon terrain de jeu. **Commencez par un seul cas d'usage.** Ne cherchez pas à tout automatiser d'un coup. Choisissez le cas qui a le meilleur rapport impact/complexité, déployez-le, mesurez les résultats, puis élargissez. **Prévoyez l'humain dans la boucle.** L'IA fait des erreurs. Votre application doit permettre à un humain de corriger, valider ou prendre le relais quand c'est nécessaire. ## Ce qu'Algomax peut faire pour vous Nous développons des [applications mobiles avec IA intégrée](/services/application-mobile-ia). Notre approche : identifier le cas d'usage qui vous apportera le plus de valeur, développer un premier module fonctionnel, mesurer les résultats, puis itérer. Nous ne vendons pas de l'IA pour le plaisir d'en mettre. Nous intégrons de l'IA quand elle résout un problème réel et mesurable. Si vous avez déjà une application et que vous souhaitez y ajouter de l'intelligence artificielle, nous pouvons intervenir sur votre code existant. Si vous partez de zéro, nous concevons l'application et l'IA ensemble, pour une intégration native et cohérente. Besoin d'un agent IA autonome, en dehors d'une application mobile ? [Découvrez nos agents IA sur-mesure](/services/agent-ia). Pour en savoir plus sur les budgets, consultez notre guide complet : [Combien coûte une application mobile en 2026 ?](/blog/combien-coute-application-mobile-2026) --- ## Combien coûte une application mobile en 2026 ? URL: https://algomax.fr/blog/combien-coute-une-application-mobile-en-2026 Publié le : 2026-02-20 Description : Prix réels, grilles tarifaires et conseils pour budgéter votre application mobile iOS et Android. Du MVP à l'app complète, avec ou sans IA. # Combien coûte une application mobile en 2026 ? Vous avez une idée d'application. Votre premier réflexe : demander un prix. Le premier freelance annonce 3 000 euros. L'agence en face, 45 000. Le troisième prestataire vous propose un "atelier de cadrage" avant de parler budget. Vous ne savez plus où donner de la tête. Le marché du développement mobile est opaque. Les prix varient d'un facteur 10 pour des projets en apparence similaires. Ce n'est pas parce que certains gonflent leurs prix. C'est parce que derrière le mot "application", il y a des réalités très différentes. Cet article pose les vrais chiffres. Ceux que nous constatons chez Algomax sur nos projets, et ceux que nous observons sur le marché français en 2026. Sans arrondir, sans cacher les postes de coût qui font mal. ## Ce qui fait varier le prix d'une application mobile Cinq facteurs expliquent 90 % de l'écart entre un devis à 5 000 euros et un devis à 60 000 euros. ### 1. La complexité des fonctionnalités Une application qui affiche une liste de produits et permet de contacter un vendeur, ce n'est pas le même projet qu'une application avec un système de réservation en temps réel, un paiement intégré, des notifications personnalisées et un espace client complet. Chaque fonctionnalité ajoute du temps de développement, de design et de test. Un système de paiement seul (Stripe, Apple Pay, Google Pay) représente entre 3 et 7 jours de travail. Un système de messagerie intégré, entre 5 et 15 jours. ### 2. Le design et l'expérience utilisateur Un design standard basé sur des composants existants coûte entre 2 000 et 5 000 euros. Un design sur-mesure avec une identité visuelle forte, des animations, des micro-interactions. Comptez 5 000 à 15 000 euros. La différence ne se voit pas toujours au premier coup d'oeil sur une maquette. Mais vos utilisateurs la ressentent. Un bon design, c'est moins de support client, plus de rétention, plus de recommandations. ### 3. Le nombre de plateformes Développer pour iOS seul, c'est un budget. Développer pour iOS et Android en même temps, c'est un budget différent, mais pas forcément le double, grâce aux technologies multiplateformes comme React Native. On y revient plus bas. ### 4. Le back-end et les intégrations L'application que vos utilisateurs voient, c'est la partie visible. Derrière, il y a le back-end (la partie invisible qui fait tourner l'application : serveur, base de données, connexions). Il y a aussi des API (des ponts de connexion entre logiciels), des connexions avec vos outils existants : CRM (gestion de la relation client), ERP (gestion d'entreprise), système de facturation. Ce back-end représente souvent 40 à 60 % du budget total. C'est le poste le plus sous-estimé dans les devis bas. ### 5. La maintenance et les mises à jour Apple et Google sortent de nouvelles versions de leurs systèmes chaque année. Les composants techniques évoluent. Les failles de sécurité doivent être corrigées. Une application mobile, ce n'est pas un projet qu'on livre et qu'on oublie. ## Grille tarifaire : du MVP à l'application complète Voici les fourchettes de prix que nous pratiquons et observons sur le marché français en 2026. ### MVP (Minimum Viable Product) : 5 000 à 15 000 euros Ce que vous obtenez : une application fonctionnelle avec les fonctionnalités essentielles. Un design propre mais pas sur-mesure. iOS et Android grâce à React Native. Un back-end simple. Convient à : un fondateur qui veut valider son idée auprès de vrais utilisateurs avant d'investir davantage. Une entreprise qui veut tester un nouveau service en interne. Délai : 4 à 8 semaines. Ce qu'il ne faut pas attendre : des performances optimales sous forte charge, un design premium, des intégrations complexes avec vos systèmes existants. ### Application complète : 15 000 à 40 000 euros Ce que vous obtenez : une application solide avec un design sur-mesure, des fonctionnalités avancées (paiement, notifications push, espace client, tableau de bord), un back-end robuste, des intégrations avec vos outils. Convient à : une PME qui lance un service digital, une startup qui a validé son MVP et passe à l'échelle, une entreprise qui veut digitaliser un processus client. Délai : 8 à 16 semaines. C'est la gamme de projets que nous réalisons le plus souvent chez Algomax. [Découvrez notre offre de développement mobile](/services/application-mobile). ### Application complexe : 40 000 euros et plus Ce que vous obtenez : une application avec des besoins spécifiques. Temps réel (chat, géolocalisation live), intelligence artificielle intégrée, conformité réglementaire, multi-langues, intégrations avec des systèmes legacy. Convient à : une ETI ou un grand compte avec des contraintes fortes. Un projet qui mélange mobile et IA. Délai : 3 à 6 mois, parfois plus. ## React Native vs développement natif : quel impact sur le prix ? C'est la question que tous nos clients posent. On la traite en profondeur dans notre [guide React Native vs Natif](/blog/react-native-vs-natif-guide-fondateur), mais voici le résumé côté budget. **Développement natif** (Swift pour iOS, Kotlin pour Android) : vous payez deux applications distinctes. Le budget est multiplié par 1,5 à 2 par rapport à une seule plateforme. La maintenance aussi. **React Native** (une seule base de code pour iOS et Android) : vous payez une seule fois le développement. L'économie est de 30 à 40 % par rapport au natif sur deux plateformes. La maintenance est centralisée. Notre recommandation chez Algomax : pour 90 % des projets d'entreprise, React Native est le bon choix. Les performances sont excellentes, l'écosystème est mature, et le retour sur investissement est nettement meilleur. On ne recommande le natif que pour des cas très spécifiques (jeux, réalité augmentée, accès hardware avancé). ## L'option IA : combien ça ajoute au budget ? Intégrer de l'intelligence artificielle dans votre application mobile, ça change le projet. Et le budget aussi. ### Les fonctionnalités IA les plus demandées **Chatbot intégré** : un assistant conversationnel dans votre app, capable de répondre aux questions de vos utilisateurs. Ajoutez 3 000 à 8 000 euros au budget initial, plus un coût récurrent pour les appels API (requêtes envoyées aux services d'IA) aux modèles de langage (les logiciels d'IA comme ChatGPT ou Mistral). **Recommandations personnalisées** : l'application apprend les préférences de chaque utilisateur et lui suggère du contenu, des produits ou des actions pertinentes. Comptez 5 000 à 12 000 euros. **Vision par ordinateur** : reconnaissance d'images, scan de documents, détection d'objets. Entre 8 000 et 20 000 euros selon la complexité. **Assistants vocaux** : votre application comprend et répond à la voix. Budget comparable à un chatbot, avec un coût de transcription en plus. Chez Algomax, nous combinons expertise mobile et IA. [Découvrez nos applications mobiles avec IA intégrée](/services/application-mobile-ia). ### Les coûts récurrents de l'IA Les fonctionnalités IA ajoutent des coûts mensuels : - **Appels API** (OpenAI, Anthropic, Mistral) : 50 à 500 euros par mois selon le volume d'utilisation - **Hébergement des modèles** (si modèle personnalisé) : 100 à 400 euros par mois - **Stockage des données IA** (les données utilisées par l'intelligence artificielle pour comprendre vos contenus) : 20 à 100 euros par mois Ces coûts sont proportionnels à votre nombre d'utilisateurs. Pour une app avec 500 utilisateurs actifs, comptez 100 à 200 euros par mois. Pour 10 000, le budget mensuel peut monter à 500-1 000 euros. ## Les coûts cachés que personne ne mentionne Quelques postes de dépense que les devis oublient régulièrement. **Les comptes développeur.** Apple Developer Program : 99 euros par an. Google Play Console : 25 euros une fois. Petit budget, mais à prévoir. **Les certificats et la sécurité.** SSL (le cadenas de sécurité sur les sites web), chiffrement des données, conformité RGPD. Rarement gratuit, rarement mentionné dans les devis. **La soumission aux stores.** La première soumission sur l'App Store prend du temps. Apple est exigeant. Comptez 1 à 3 jours de travail pour gérer les allers-retours avec la review Apple. **Le contenu.** Votre application a besoin de textes, d'images, parfois de vidéos. Si vous ne les fournissez pas, quelqu'un doit les créer. Ce n'est jamais inclus dans un devis de développement. **L'analytics et le monitoring.** Savoir comment vos utilisateurs se comportent dans l'app, détecter les crashs, mesurer la performance. Les outils existent (Firebase, Sentry), mais leur intégration et leur configuration prennent du temps. ## Comment calculer le ROI de votre application Le ROI dépend de ce que l'application remplace ou génère. ### Cas 1 : application qui remplace un processus manuel Une entreprise de services gère ses rendez-vous par téléphone. Deux personnes y consacrent 50 % de leur temps. Coût annuel : environ 40 000 euros. Une application de prise de rendez-vous automatisée coûte 20 000 euros à développer, 300 euros par mois à maintenir. Elle absorbe 80 % des prises de rendez-vous. Économie année 1 : 32 000 euros de temps libéré, moins 23 600 euros d'investissement = 8 400 euros de gain net. Année 2 : le ROI s'envole puisque le développement est amorti. ### Cas 2 : application qui génère du revenu Un commerce lance une application de click-and-collect. Investissement : 25 000 euros. L'application génère 15 % de commandes supplémentaires, soit 4 000 euros de chiffre d'affaires mensuel additionnel. Le retour sur investissement est atteint en 7 mois. ## Comment choisir votre prestataire Cinq critères pour éviter les mauvaises surprises. **Demandez des références dans votre secteur.** Un développeur qui a livré 10 applications e-commerce saura anticiper les pièges que vous ne voyez pas. **Exigez un devis détaillé.** Si le devis tient sur une ligne ("Développement application mobile : 15 000 euros"), fuyez. Vous devez voir le détail : design, développement front, développement back, intégrations, tests, déploiement, formation. **Clarifiez la propriété du code.** Vous devez être propriétaire du code source à la livraison. C'est non négociable. **Posez la question de la maintenance.** Qui maintient l'application après la livraison ? À quel tarif ? Avec quel délai d'intervention ? **Vérifiez la stack technique.** Si le prestataire utilise une technologie propriétaire ou un no-code qui vous enferme, vous serez dépendant de lui pour toute évolution future. ## Ce que vous payez chez Algomax Nous développons des applications mobiles iOS et Android avec React Native. Notre approche : livrer vite, itérer souvent, et intégrer l'IA quand elle apporte une vraie valeur. | Offre | Prix | Ce que vous obtenez | Délai | |---|---|---|---| | **MVP** | 5 000 - 15 000 € | App fonctionnelle, design standard, iOS + Android | 4-8 semaines | | **App complète** | 15 000 - 40 000 € | Design sur-mesure, fonctionnalités avancées, intégrations | 8-16 semaines | | **App + IA** | 25 000 - 60 000 € | Tout ce qui précède + fonctionnalités IA intégrées | 10-20 semaines | [Consultez notre offre de développement mobile](/services/application-mobile) ou [découvrez nos applications mobiles avec IA](/services/application-mobile-ia). ## Le bon réflexe avant de vous lancer Ne commencez pas par la technologie. Commencez par le problème. Quelle douleur votre application résout-elle ? Pour qui ? Combien cette douleur coûte-t-elle aujourd'hui ? Si vous ne pouvez pas répondre clairement à ces trois questions, il est trop tôt pour demander un devis. Une fois le problème clarifié, un bon prestataire pourra vous proposer la solution la plus adaptée, pas la plus chère. Chez Algomax, on commence toujours par comprendre votre métier avant de parler technologie. Parce qu'une application bien pensée à 15 000 euros vaut infiniment plus qu'une application mal cadrée à 50 000. --- ## Quel ordinateur choisir pour coder en 2026 ? URL: https://algomax.fr/blog/quel-ordinateur-choisir-pour-coder-en-2025-guide-complet-pour-debutants-en-developpement-web Publié le : 2025-05-21 Description : Mac, PC ou Linux ? Le guide 2026 pour choisir un ordinateur de développement selon votre budget, vos besoins et votre stack. > Mise à jour SEO (Mars 2026) > > Version 2026: configuration minimale recommandée, bons compromis budget/perf et erreurs à éviter pour coder confortablement. # Quel ordinateur choisir pour coder en 2026 ? Vous voulez apprendre à coder. Ou bien vous recrutez un développeur et vous vous demandez quel matériel lui fournir. Dans les deux cas, la question revient toujours : quel ordinateur acheter ? Bonne nouvelle : il n'y a pas besoin d'un monstre de puissance pour faire du développement web. Un navigateur, un éditeur de code, un terminal. C'est tout. L'essentiel, c'est de ne pas se tromper sur quelques critères simples. Ce guide est fait pour les débutants complets et pour les dirigeants qui veulent comprendre les besoins techniques de leur équipe sans se faire avoir par le marketing. ## Les trois critères qui comptent vraiment ### La RAM (mémoire vive) La RAM, c'est la mémoire de travail de votre ordinateur. Quand vous ouvrez votre éditeur de code, un navigateur avec 15 onglets, un terminal et un outil de design, tout ça consomme de la RAM. **Minimum absolu : 8 Go.** C'est suffisant pour débuter en HTML, CSS et JavaScript simple. **Recommandé : 16 Go.** Dès que vous travaillez avec des frameworks modernes (React, Next.js) ou que vous faites tourner des conteneurs Docker (des environnements de développement isolés), 8 Go deviennent justes. Vous allez sentir des ralentissements. 16 Go règle le problème pour 95 % des cas. **32 Go et plus.** Utile si vous faites tourner des modèles d'intelligence artificielle en local, si vous développez des applications lourdes ou si vous travaillez simultanément sur plusieurs projets. Pour du développement web standard, c'est du luxe. ### Le processeur En 2026, deux familles dominent le marché. **Apple Silicon (M3, M4, M4 Pro).** Les puces Apple sont excellentes pour le développement. Elles consomment peu d'énergie, ne chauffent presque pas et offrent des performances remarquables. Un MacBook Air M4 avec 16 Go de RAM est une machine de travail redoutable pour le développement web. **AMD Ryzen / Intel Core Ultra.** Côté PC, les Ryzen 7 et 9 d'AMD restent de très bons choix. Intel a rattrapé son retard avec la gamme Core Ultra 200, mais les benchmarks montrent qu'AMD garde un avantage en rapport performance/prix sur les portables. Pour du développement web, un processeur milieu de gamme suffit largement. Vous n'avez pas besoin d'un i9 ou d'un M4 Max. Le goulot d'étranglement, c'est presque toujours la RAM, pas le processeur. ### Le stockage SSD Oubliez les disques durs classiques. En 2026, tout le monde devrait être sur SSD (un type de stockage rapide, sans pièces mécaniques). **256 Go : trop juste.** Entre le système d'exploitation, vos outils, vos projets et les fichiers temporaires, vous allez manquer de place en quelques mois. **512 Go : le minimum confortable.** Ça passe pour la plupart des développeurs web. **1 To : tranquille.** Si vous travaillez avec du multimédia, des bases de données locales ou si vous ne voulez simplement pas vous soucier de l'espace. ## Mac, PC Windows ou Linux ? C'est LA question qui déclenche des débats sans fin dans la communauté dev. Voici ce qu'il faut retenir. ### macOS (MacBook Air / MacBook Pro) Le choix le plus populaire chez les développeurs web, et pour de bonnes raisons. macOS est basé sur Unix, ce qui signifie que le terminal fonctionne de la même manière que sur les serveurs où tournent vos applications en production. Les commandes que vous apprenez sur votre Mac fonctionnent telles quelles sur un serveur Linux. C'est un vrai avantage au quotidien. L'écosystème Apple en 2026 est solide. Les puces M4 offrent une autonomie de 15 à 20 heures sur le MacBook Air. Le trackpad est le meilleur du marché. L'écran est excellent. Et Homebrew (le gestionnaire de paquets pour installer des outils de développement) rend l'installation très simple. **Le point faible : le prix.** Un MacBook Air M4 avec 16 Go de RAM et 512 Go de SSD coûte environ 1 500 euros. C'est un investissement. **Recommandé pour :** les débutants qui veulent un environnement "ça marche tout de suite", les développeurs front-end, les équipes qui déploient sur des serveurs Linux. ### Windows Windows a fait d'énormes progrès pour les développeurs grâce à WSL2 (Windows Subsystem for Linux, un outil qui permet de faire tourner un environnement Linux directement dans Windows). Pas besoin de dual boot, pas de machine virtuelle lente. C'est une option viable en 2026. La plupart des outils de développement web fonctionnent bien sur Windows. VS Code est développé par Microsoft et s'intègre parfaitement avec WSL2. **L'avantage : le rapport qualité/prix.** Vous pouvez trouver un excellent portable avec 16 Go de RAM et 512 Go de SSD pour 800 à 1 000 euros. C'est 30 à 40 % moins cher qu'un MacBook équivalent. **Le point faible :** certains outils et tutoriels supposent un environnement Unix. Vous passerez un peu plus de temps à configurer votre environnement au début. Rien de dramatique avec WSL2, mais c'est une étape supplémentaire. **Recommandé pour :** ceux qui ont un budget serré, les développeurs qui travaillent aussi avec des outils Microsoft (.NET, Azure), les utilisateurs qui veulent un seul portable polyvalent. ### Linux Si vous installez Ubuntu ou Fedora sur un portable, vous obtenez l'environnement le plus proche de ce qui tourne en production. Pas de couche intermédiaire, pas de compatibilité à gérer. C'est le choix des puristes. En pratique, Linux demande un peu plus de patience pour la configuration matérielle (Wi-Fi, Bluetooth, écrans externes). En 2026, c'est beaucoup mieux qu'avant, surtout sur les ThinkPad de Lenovo et les Dell XPS qui sont testés avec Linux. **Recommandé pour :** les développeurs back-end, les équipes DevOps, ou ceux qui veulent comprendre le système en profondeur. Moins conseillé pour un débutant complet. ## Nos recommandations concrètes par budget ### Budget serré (500 à 800 euros) - **Lenovo IdeaPad 5** avec AMD Ryzen 5, 16 Go RAM, 512 Go SSD. Excellent rapport qualité/prix sous Windows. - **Acer Swift Go 14** avec AMD Ryzen 7, 16 Go RAM. Léger et performant pour ce prix. - **Reconditionné : ThinkPad T14s** (génération précédente). Les ThinkPad sont des machines de travail solides. Un modèle de 2024 reconditionné avec 16 Go de RAM se trouve autour de 600 euros. ### Budget confortable (1 000 à 1 600 euros) - **MacBook Air M4 16 Go / 512 Go.** Le meilleur choix global pour un développeur web en 2026. Silence total (pas de ventilateur), autonomie énorme, écran superbe. - **Lenovo ThinkPad T14s Gen 6** avec Ryzen 7 PRO, 32 Go RAM. La référence sous Windows/Linux pour le travail sérieux. - **ASUS Zenbook 14 OLED.** Écran magnifique, 16 Go RAM, processeur AMD Ryzen 7. Un bon compromis entre plaisir visuel et performance. ### Budget généreux (1 600 euros et plus) - **MacBook Pro 14" M4 Pro.** Pour ceux qui font du développement lourd, compilent souvent, ou font tourner des modèles d'IA en local. Le M4 Pro avec 24 Go de RAM est une bête de course. - **Framework Laptop 16.** Le portable modulaire où vous pouvez changer chaque composant. Idéal si vous voulez un PC évolutif sous Linux. ## Écran, clavier et périphériques Un point souvent négligé : votre écran externe. Si vous codez plus de 4 heures par jour, investissez dans un moniteur 27 pouces en résolution QHD (2560x1440) minimum. Votre dos et vos yeux vous remercieront. Un bon écran externe coûte entre 250 et 400 euros. C'est un investissement qui a plus d'impact sur votre productivité qu'un processeur plus rapide. Pour le clavier : si vous codez beaucoup, un clavier mécanique externe améliore considérablement le confort de frappe. Comptez 80 à 150 euros pour un bon modèle. ## Portable ou fixe ? Pour un débutant : portable. Vous voulez pouvoir coder depuis un café, un coworking ou votre canapé. La flexibilité compte. Pour un poste fixe en entreprise : un bon portable branché sur un écran externe et un clavier mécanique. Vous avez le meilleur des deux mondes. Les tours fixes n'ont de sens en développement web que si vous faites de la virtualisation massive ou de l'entraînement de modèles d'IA. Pour 99 % des projets web, un portable suffit. ## L'erreur classique à éviter Ne tombez pas dans le piège du "j'achèterai un meilleur PC quand je serai plus avancé". C'est l'inverse. Un débutant a besoin d'une machine fiable qui ne le ralentit pas. Rien de plus frustrant que d'attendre 30 secondes à chaque compilation quand on essaie d'apprendre. Investissez dans 16 Go de RAM et un SSD. Le reste est secondaire. ## Et si vous ne voulez pas coder vous-même ? Peut-être que vous lisez cet article parce que vous envisagez de vous lancer dans le code. Ou peut-être que vous êtes un fondateur qui se demande s'il devrait apprendre à coder ou déléguer. Si votre objectif est de lancer un produit (une application web, un SaaS, un outil interne), apprendre à coder prendra des mois avant d'être productif. Ce temps peut être mieux investi dans votre coeur de métier. Chez Algomax, nous construisons des [applications web](/services/application-web) et des [plateformes SaaS](/services/application-saas) pour les fondateurs qui veulent avancer vite. Si vous avez un projet en tête, [contactez-nous](/contact). On vous dira honnêtement si vous avez besoin de coder vous-même ou si on peut vous aider à gagner du temps. ## Aller plus loin avec Algomax - [Développement d'agent IA sur mesure](/services/agent-ia) - [Création d'application SaaS](/services/application-saas) - [Développement d'application mobile](/services/application-mobile) - [Agence IA à Strasbourg](/agence-strasbourg) --- ## Pour aller plus loin Le bon setup ne suffit pas, il faut aussi un projet qui tient la route : - Tu veux concevoir ton app ? [Comment créer une application mobile en 2026 (guide complet)](/blog/guide-complet-de-la-conception-d-une-application-mobile-de-a-a-z). - Tu cherches à automatiser un process ? [Agent IA WhatsApp pour entreprises](/services/agent-ia-whatsapp) ou [chatbot Telegram](/services/agent-ia-telegram). - Tu préfères externaliser : [agence web, mobile et agents IA à Strasbourg](/agence-strasbourg). --- ## Comment devenir développeur web en 2026 : le guide pour bien démarrer URL: https://algomax.fr/blog/comment-devenir-developpeur-web-:-le-guide-complet-pour-bien-demarrer-en-2025 Publié le : 2025-05-21 Description : Le guide complet pour devenir développeur web en 2026. Formations, technologies, premier emploi : tout ce qu'il faut savoir pour se lancer. # Comment devenir développeur web en 2026 : le guide pour bien démarrer Le développement web est l'un des métiers les plus accessibles du numérique. Pas besoin de diplôme spécifique. Pas besoin d'avoir commencé à 12 ans. Des gens se reconvertissent chaque année, à 25, 35 ou 45 ans, et trouvent un emploi en quelques mois. Mais le chemin est semé d'informations contradictoires. Faut-il apprendre React ou Vue ? Faire une formation payante ou apprendre seul ? Est-ce que l'IA va remplacer les développeurs ? Ce guide est écrit pour ceux qui partent de zéro. Si vous êtes un fondateur qui veut comprendre comment fonctionne le monde du développement web (pour mieux recruter ou mieux briefer un prestataire), vous y trouverez aussi votre compte. ## C'est quoi, un développeur web ? Un développeur web construit des sites internet et des applications qui fonctionnent dans un navigateur. C'est large. Ça va du site vitrine d'une boulangerie au tableau de bord en temps réel d'une fintech. Il existe trois grandes spécialisations. ### Front-end Le front-end, c'est tout ce que l'utilisateur voit et touche. Les boutons, les menus, les animations, la mise en page. Quand vous naviguez sur un site et que ça répond bien au clic, c'est le travail du développeur front-end. Technologies principales : HTML (la structure des pages), CSS (le style visuel), JavaScript (l'interactivité), et un framework comme React, Vue.js ou Svelte. ### Back-end Le back-end, c'est tout ce qui se passe en coulisses. Quand vous vous connectez à un site, le back-end vérifie votre mot de passe. Quand vous passez une commande, le back-end enregistre la transaction dans une base de données, envoie un email de confirmation et met à jour le stock. Technologies principales : Node.js (JavaScript côté serveur), Python, PHP, Go. Plus une base de données comme PostgreSQL ou MongoDB. ### Full-stack Un développeur full-stack fait les deux. C'est le profil le plus recherché par les petites entreprises et les startups, parce qu'il peut construire un produit de bout en bout. En 2026, être full-stack ne signifie pas tout maîtriser parfaitement. Ça veut dire être capable de travailler des deux côtés, avec une préférence pour l'un ou l'autre. ## Par où commencer ? Voici un parcours réaliste. Pas un programme de 18 mois. Un chemin progressif qui vous rend employable. ### Étape 1 : Les bases (4 à 6 semaines) **HTML et CSS.** C'est la fondation. HTML structure le contenu d'une page. CSS le met en forme. On ne peut pas sauter cette étape, même si c'est tentant d'aller directement vers les frameworks. Objectif concret : construire 3 à 5 pages web statiques. Une page personnelle, un faux site de restaurant, un portfolio. Pas besoin que ce soit beau. Il faut que ça fonctionne. Si vous voulez un guide pas à pas pour créer votre premier site, on a écrit un [tutoriel dédié](/blog/creer-son-premier-site-avec-htmlcss-en-moins-de-2h). **Ressources gratuites :** freeCodeCamp (en anglais), OpenClassrooms (en français), MDN Web Docs de Mozilla. ### Étape 2 : JavaScript (6 à 8 semaines) JavaScript, c'est le langage qui rend les pages web interactives. Sans JavaScript, une page web est un document. Avec JavaScript, c'est une application. Concentrez-vous sur les fondamentaux : variables, fonctions, boucles, tableaux, objets, manipulation du DOM (c'est-à-dire modifier la page en temps réel via le code). Ne touchez pas aux frameworks tout de suite. Apprenez à faire des choses simples en JavaScript pur. Objectif concret : construire un petit projet interactif. Une to-do list. Un jeu de quiz. Un convertisseur de devises. Quelque chose qui répond aux actions de l'utilisateur. ### Étape 3 : Un framework front-end (4 à 6 semaines) En 2026, React reste le framework le plus demandé sur le marché de l'emploi en France. C'est un fait, pas une opinion. Regardez les offres d'emploi : React est cité dans la majorité. Vue.js est une excellente alternative, plus facile à apprendre et très populaire en France. Svelte monte en puissance mais les offres d'emploi restent rares. **Notre conseil : apprenez React.** Si vous trouvez ça trop compliqué, basculez sur Vue.js. L'important n'est pas le framework, c'est de comprendre les concepts : composants, état (state), rendu conditionnel, appels à des services externes via des API. ### Étape 4 : Le back-end (6 à 8 semaines) Vous avez deux options principales. **Node.js avec Express ou Fastify.** L'avantage : vous restez en JavaScript. Pas besoin d'apprendre un nouveau langage. C'est le choix le plus logique si vous venez du front-end. **Python avec Django ou FastAPI.** Python est plus lisible pour un débutant. Django inclut beaucoup de choses par défaut (authentification, panneau d'administration, accès à la base de données). FastAPI est plus moderne et performant. Dans les deux cas, apprenez à créer une API REST (un système qui permet à votre application de communiquer avec un serveur), à vous connecter à une base de données PostgreSQL, à gérer l'authentification. ### Étape 5 : Un vrai projet (4 à 8 semaines) C'est l'étape la plus importante. Plus importante que toutes les formations du monde. Construisez quelque chose qui vous intéresse. Une application de suivi de budget. Un outil de gestion de recettes de cuisine. Un clone simplifié de Twitter. Quelque chose d'assez complexe pour vous forcer à résoudre de vrais problèmes, mais pas tellement ambitieux que vous abandonniez après deux semaines. Mettez le code sur GitHub. Déployez-le en ligne (Vercel pour le front-end, Railway ou Fly.io pour le back-end). Un recruteur veut voir du code qui tourne, pas une liste de certificats. ## Les outils à connaître en 2026 Au-delà des langages, certains outils sont attendus partout. **Git et GitHub.** Le système de gestion de versions, qui permet de suivre l'historique de votre code et de collaborer avec d'autres développeurs. C'est non négociable. Apprenez les bases : commit, push, pull, branches, pull requests. Ça prend une journée pour les fondamentaux. **VS Code.** L'éditeur de code le plus utilisé au monde. Gratuit, extensible, avec des milliers d'extensions. Il n'y a aucune raison d'utiliser autre chose quand on débute. **Le terminal.** Savoir naviguer dans des dossiers, lancer des commandes, installer des paquets. Pas besoin d'être un expert Linux, mais les bases sont essentielles. **Docker.** Pas indispensable pour un junior, mais de plus en plus demandé. Docker permet de faire tourner vos applications dans des environnements isolés et reproductibles. À découvrir une fois que vous êtes à l'aise avec le reste. ## Et l'IA dans tout ça ? Parlons de l'éléphant dans la pièce. Oui, les outils d'IA générative comme GitHub Copilot, Cursor ou Claude écrivent du code. Oui, ça change le métier. Non, ça ne va pas supprimer les développeurs web en 2026. Ce qui change : les tâches répétitives sont automatisées. Écrire un formulaire de contact, générer une requête de base de données basique, créer un composant standard. Tout ça va beaucoup plus vite avec un assistant IA. Ce qui ne change pas : comprendre ce qu'on construit, prendre des décisions d'architecture, débugger un problème subtil, communiquer avec un client sur ses besoins. Ça reste du travail humain. En pratique, un développeur junior en 2026 qui sait utiliser les outils d'IA est plus productif qu'un junior de 2023. C'est un multiplicateur, pas un remplaçant. **Conseil concret :** apprenez à coder d'abord sans IA. Comprenez ce que fait chaque ligne. Ensuite, intégrez les outils d'IA pour aller plus vite. Si vous utilisez l'IA avant de comprendre les bases, vous ne saurez pas évaluer si le code généré est correct. Et il ne l'est pas toujours. ## Les formations : gratuit, bootcamp ou école ? ### Apprendre seul (gratuit ou presque) C'est possible. Des milliers de personnes l'ont fait. Les ressources sont abondantes : freeCodeCamp, The Odin Project, les documentations officielles, YouTube. L'avantage : c'est gratuit et vous avancez à votre rythme. L'inconvénient : ça demande beaucoup de discipline. Comptez 6 à 12 mois à temps plein, ou 12 à 18 mois en parallèle d'un emploi. ### Les bootcamps (2 à 6 mois, 5 000 à 10 000 euros) Le Wagon, Ironhack, Wild Code School, O'Clock. Ces formations intensives vous emmènent de zéro à "employable" en quelques mois. Le rythme est soutenu. La qualité varie. L'avantage : structure, encadrement, réseau d'anciens élèves. L'inconvénient : le prix, et le fait que quelques mois ne suffisent pas pour maîtriser le métier. Vous sortez junior, et c'est normal. Vérifiez les taux d'insertion professionnelle. Demandez à parler à d'anciens élèves. Méfiez-vous des statistiques trop belles. ### Les écoles et formations longues (1 à 5 ans) DUT Informatique, licence pro, école d'ingénieurs, master. C'est le chemin classique. Il donne une base théorique solide (algorithmes, réseaux, systèmes) mais met plus de temps avant d'être concrètement opérationnel sur du développement web moderne. En 2026, le diplôme compte moins que le portfolio. Un recruteur regarde votre GitHub avant votre CV. Mais un diplôme ouvre des portes dans les grandes entreprises et facilite la négociation salariale. ## Le marché de l'emploi en 2026 Soyons honnêtes : le marché s'est tendu. Après l'euphorie post-COVID où les développeurs juniors se faisaient recruter en une semaine, la concurrence est plus forte. Les entreprises sont plus exigeantes. Ce qui est recherché : - **Développeurs full-stack JavaScript** (React + Node.js). Le profil le plus demandé. - **Développeurs Python** pour tout ce qui touche à la data et à l'intelligence artificielle. - **Profils qui comprennent l'IA.** Savoir intégrer une API d'IA générative dans une application, c'est une compétence qui vous distingue immédiatement. Fourchette de salaires en France pour un premier poste : 30 000 à 38 000 euros brut annuel en province, 35 000 à 45 000 euros à Paris. En freelance, comptez 250 à 400 euros par jour pour un profil junior. ## Les erreurs qui font perdre du temps **Changer de langage ou de framework toutes les deux semaines.** Vous suivez un tuto React, puis vous lisez que Vue est mieux, alors vous recommencez, puis quelqu'un vous dit de faire du Svelte. Stop. Choisissez une stack et tenez-la pendant au moins 3 mois. **Ne pas construire de projets personnels.** Les cours et les exercices guidés ne suffisent pas. La vraie progression vient du moment où vous êtes bloqué sur un problème que personne n'a résolu pour vous. **Ignorer les bases.** Si vous ne comprenez pas comment JavaScript gère les fonctions et les objets, React vous paraîtra magique et incompréhensible. Les fondamentaux d'abord, toujours. **Postuler sans portfolio.** Votre GitHub est votre CV technique. Deux ou trois projets propres, bien documentés, déployés en ligne. Ça vaut plus que n'importe quelle certification. ## Un dernier mot pour les fondateurs Si vous êtes un dirigeant non-technique et que vous avez lu ce guide pour mieux comprendre le monde du développement, voici le résumé. Recruter un bon développeur prend du temps. Former un junior aussi. Et pendant ce temps, votre produit n'avance pas. Chez Algomax, nous accompagnons les fondateurs qui veulent construire leur produit sans attendre. [Applications web](/services/application-web), [plateformes SaaS](/services/application-saas), [applications mobiles](/services/application-mobile), on couvre toute la chaîne. Et si votre projet a besoin d'intelligence artificielle, nous développons aussi des [agents IA sur mesure](/services/agent-ia-sur-mesure) et des [automatisations](/services/automatisation-n8n). Vous avez une idée ? [Parlons-en](/contact). --- ## Les 10 meilleurs hooks avec React Router 7 (anciennement Remix) URL: https://algomax.fr/blog/les-10-meilleurs-hooks-avec-react-router-7-anciennement-remix Publié le : 2025-01-12 Description : Voici 10 hooks que j'utilise le plus dans mes applications Remix / React Router 7. Dans cet article, je partage avec vous mes **hooks** préférés pour [React Router 7](https://reactrouter.com/) (anciennement [Remix](https://remix.run)), que j’utilise dans quasiment tous mes projets. ## 1. useOptionalUser C'est le hook que j'utilise le plus. Il permet de récupérer les informations optionnelles d'un utilisateur. Pour le faire fonctionner, il suffit de renvoyer un utilisateur dans le fichier `app/routes/root.tsx` (fichier racine d'une application Remix). Toute donnée chargée dans `root` est présente partout dans l'application (comme un contexte global). ```tsx useOptionalUser.tsx import { useRouteLoaderData } from "@remix-run/react"; import type { loader } from "app/root"; export const useOptionalUser = () => { const data = useRouteLoaderData("root"); if (data?.user) { return data.user; } return null; }; export function useUser() { const maybeUser = useOptionalUser(); if (!maybeUser) { throw new Error( "No user found in root loader, but user is required by useUser. If user is optional, try useOptionalUser instead.", ); } return maybeUser; } ``` Comme on utilise le type générique du hook `useRouteLoaderData`, ce hook renvoie une donnée typée. Merci Typescript ! > Notez que l'on exporte également un hook `useUser` qui exploite le hook `useOptionalUser`, mais qui renvoie une erreur en cas d'utilisateur déconnecter. Cela permet de protéger les pages côté client en renvoyant une erreur en cas d'utilisateur non identifié. ## 2. useTailwindScreenSizes J'utilise ce hook pour afficher un bandeau indiquant la taille d'écran active de TailwindCSS. Ces dimensions utilises les valeurs par défaut, qu'on retrouve dans la [documentation officielle de TailwindCSS](https://tailwindcss.com/docs/responsive-design) ```tsx useTailwindScreenSizes import React from "react"; export const useTailwindScreenSizes = ({ initialWidth = 1280, }: { initialWidth?: number; }) => { const [currentWidth, setCurrentWidth] = React.useState(initialWidth); React.useEffect(() => { if (typeof window === "undefined") return; const handleScreenResize = () => { const width = window.innerWidth; setCurrentWidth(width); }; handleScreenResize(); window.addEventListener("resize", handleScreenResize); return () => { window.removeEventListener("resize", handleScreenResize); }; }, []); const getResponsive = () => { if (currentWidth > 1536) { return "2xl"; } if (currentWidth > 1280) { return "xl"; } if (currentWidth > 1024) { return "lg"; } if (currentWidth > 768) { return "md"; } if (currentWidth > 640) { return "sm"; } return "very small"; }; return { currentWidth, getResponsive }; }; ``` J'appelle ensuite ce hook dans un composant nommé `DevTool` que je place de manière absolue. Dans le fichier `root` par exemple. ```tsx Devtool.tsx import { useIsClient } from "hooks/useIsClient.tsx"; import { useTailwindScreenSizes } from "hooks/useTailwindScreenSizes.tsx"; const Devtool = ({ initialScreenWidth = 1280, }: { initialScreenWidth?: number; }) => { const { currentWidth, getResponsive } = useTailwindScreenSizes({ initialWidth: initialScreenWidth, }); const isClient = useIsClient(); if (!isClient) return null; return (
{currentWidth} {getResponsive()}
); }; export default Devtool; ``` ## 3. useIsClient Ce hook utilise-lui même un hook nommé `useIsClient`, n'affichant rien côté serveur (on affiche ce composant côté client). ```tsx useIsClient.tsx import { useEffect, useState } from "react"; export function useIsClient() { const [isClient, setClient] = useState(false); useEffect(() => { setClient(true); }, []); return isClient; } ``` ## 4. useGetUserPosition Avez-vous déjà eu besoin de connaître la position géographique des utilisateurs de votre site ? On parle ici de *latitude* et *longitude*, qui permettent de calculer la distance kilométrique entre deux points. C'est notamment utile pour géolocaliser l'utilisateur et lui proposer des données locales (c'est utilisé sur [Leboncoin](https://leboncoin.fr), [Airbnb](https://airbnb.com), [Uber](https://uber.com) ... J'ai utilisé ce hook pour la recherche d'adresse de [GoodCollect](https://goodcollect.co). ```tsx useGetUserPosition.tsx import { useState } from "react"; import { useToast } from "components/shadcn-ui/use-toast.ts"; export const useGetUserPosition = ({ successFn = () => {}, }: { successFn?: ({ lat, lng }: { lat: number; lng: number }) => void; }) => { const [latLng, setLatLng] = useState<{ loading: boolean; latitude: number | null; longitude: number | null; canGeoLocate: boolean; }>({ loading: false, latitude: null, longitude: null, canGeoLocate: true, }); const { toast } = useToast(); const getUserPosition = () => { if (!navigator.geolocation) { setLatLng((oldValues) => ({ ...oldValues, canGeoLocate: false, })); return; } setLatLng((oldValues) => ({ ...oldValues, loading: true })); navigator.geolocation.getCurrentPosition( (position) => { const { latitude, longitude } = position.coords; setLatLng((oldValues) => ({ ...oldValues, latitude, longitude, loading: false, })); successFn?.({ lat: latitude, lng: longitude }); }, (error) => { if (error.PERMISSION_DENIED) { toast({ description: "Votre navigateur n'a pas les permissions pour vous localiser. Vous pouvez l'activer dans les paramètres de votre navigateur.", variant: "error", }); } else if (error.TIMEOUT) { toast({ description: "La géolocalisation a pris trop de temps. Veuillez réessayer.", variant: "error", }); } else if (error.POSITION_UNAVAILABLE) { toast({ description: "Votre position n'a pas pu être déterminée. Veuillez réessayer.", variant: "error", }); } else { toast({ description: "Une erreur est survenue. Veuillez réessayer.", variant: "error", }); } setLatLng((oldValues) => ({ ...oldValues, loading: false, })); }, { timeout: 10_000, enableHighAccuracy: true, maximumAge: 60_000, // 60 seconds }, ); }; return { getUserPosition, latLng }; }; ``` Ce hook renvoie les valeurs suivantes : - la latitude et longitude - est-ce que l'utilisateur a accepté d'être géolocalisé / est-ce qu'il peut être géolicalisé - est-ce que la géolocalisation est en cours (booléen *loading*) Pour connaître la position, nous utilisons l'API native `navigator.geolocation.getCurrentPosition`. Ce hook utilise également le hook `useToast` qui est entièrement facultatif, et qui permet d'afficher une alerte en cas d'erreur. Ce hook est fourni avec le composant [toast](https://ui.shadcn.com/docs/components/toast) de la librairie **shadcn/ui**. ## 6. useFileUpload Ce hook permet d'afficher un fichier chargé depuis un *input* de type `file`. Le code est à adadpté à votre cas d'utilisation. Le cas d'utilisation n'accepte que les fichiers images ou de type PDF. Il met à disposition plusieurs propriétés pour réinitialiser l'input, afficher le fichier et savoir si c'est une image. ```tsx useFileUpload.tsx import React from "react"; // Takes a file path and returns the file name and extension const checkFilenameFormat = ({ fileName, allowedFormats = ["jpg", "jpeg", "png", "heif", "avif", "webp", "pdf"], }: { fileName: string; allowedFormats?: string[]; }) => { const fileExtension = fileName.split(".").pop() || ""; // remove the dot // Only allow image files const isFormatAllowed = allowedFormats.includes(fileExtension); const isImage = fileExtension !== "pdf"; return { isImage, isFormatAllowed, fileExtension }; }; export const useFileUpload = () => { const [fileUpload, setFileUpload] = React.useState(null); const [documentPreview, setDocumentPreview] = React.useState( null, ); interface HtmlFormElement extends HTMLInputElement { files: FileList; } const handleFileUpload = (e: React.ChangeEvent) => { const [file] = e.target.files || []; if (file) { setFileUpload(file); } else { setFileUpload(null); } }; const isFileImage = React.useMemo(() => { if (!fileUpload) return null; const fileFormat = checkFilenameFormat({ fileName: fileUpload?.name || "", }); return fileFormat.isImage; }, [fileUpload]); // This create a preview of the file, as a URL React.useEffect(() => { if (!fileUpload) return; const objectUrl = URL.createObjectURL(fileUpload); setDocumentPreview(objectUrl); return () => URL.revokeObjectURL(objectUrl); }, [fileUpload]); const resetFileUpload = () => { setFileUpload(null); setDocumentPreview(null); }; return { isFileImage, documentPreview, setFileUpload, fileUpload, handleFileUpload, resetFileUpload, }; }; ``` Il suffit de l'utiliser avec input de type "file" pour le faire fonctionner. ```tsx const { documentPreview, handleFileUpload, isFileImage, resetFileUpload } = useFileUpload(); ``` ## 7. useAddressCombobox J'ai découvert ce hook en lisant l'article de [Kent C. Dodds](https://kentcdodds.com/) nommé [Full Stack Components](https://www.epicweb.dev/full-stack-components). Dedans, il nous explique la notion de composant full-stack : On déclare une route, mais au lieu de renvoyer une vue directement, nous exportons depuis cette route un hook, qui est typé et que nous pouvons ensuite utiliser partout. Parfait pour un *combobox* d'adresse autocomplétée par exemple. Je l'ai adaptée pour utiliser l'API de Google ([Places API](https://developers.google.com/maps/documentation/places/web-service/overview)) et obtenir l'auto-complétion des adresses. Ce hook nécessite de télécharger deux librairies pour fonctionner : - [Downshift](https://www.downshift-js.com/), une librairie que Kent a lui-même mis en place lors de sa mission à Paypal - [spin-delay](https://github.com/smeijer/spin-delay) pour afficher un spinner (suffisamment longtemps lors des petits chargements) ```tsx useAddressCombobox import { useFetcher, useSearchParams } from "@remix-run/react"; import { useCombobox } from "downshift"; import { useEffect, useId, useState } from "react"; import { flushSync } from "react-dom"; import type { AddressComboboxType } from "routes/get-address"; import { useSpinDelay } from "spin-delay"; export const useAddressCombobox = ({ defaultAddress = null, defaultPlaceId = null, onAddressChange, }: { defaultAddress?: string | null; defaultPlaceId?: string | null; onAddressChange?: ({ address, placeId, }: { address: string; placeId: string; }) => void; }) => { const addressFetcher = useFetcher(); const addressAvailabilityFetcher = useFetcher(); const id = useId(); const addresses = addressFetcher.data?.addresses ?? []; type AddressType = (typeof addresses)[number]; const [selectedAddress, setSelectedAddress] = useState< null | undefined | AddressType >({ address: defaultAddress ?? "", id: defaultPlaceId ?? "", }); // An errored address is an address that was suggested by Google, but that is not associated with a zipcode. const [searchParams] = useSearchParams(); const cb = useCombobox({ id, onSelectedItemChange: ({ selectedItem }) => { setSelectedAddress(selectedItem); }, items: addresses, itemToString: (item) => (item ? item.address : ""), defaultInputValue: defaultAddress ?? searchParams.get("address") ?? "", onInputValueChange: (changes) => { addressFetcher.submit( { search: changes.inputValue ?? "" }, { method: "get", action: "/get-address" }, ); }, }); const busy = addressFetcher.state !== "idle"; const showSpinner = useSpinDelay(busy, { delay: 150, minDuration: 500, }); const displayMenu = cb.isOpen && addresses.length > 0; return { displayMenu, showSpinner, selectedAddress, cb, addressFetcher, addresses, }; }; ``` ## 8. useDateRanges Pour les applications nécessitant de manipuler des dates, voici un hook permettant de les formatter sous forme de `string`. Elles peuvent ensuite être sauvegardées dans l'URL (sur les sites de réservation par exemple). Nous exploitons dans ce hook la librairie [date-fns](https://date-fns.org) pour formatter la date. ```tsx useDateRanges.tsx import { parseStringToDate } from "app/shared/dates.ts"; import { differenceInDays } from "date-fns"; import React, { useMemo } from "react"; import { useSearchParams } from "react-router"; const getDateDifferenceInDays = ({ endDate, startDate, }: { endDate: Date; startDate: Date; }) => { // Always add more day, to include the current day const dateDifferenceInDays = differenceInDays(endDate, startDate) + 1; return dateDifferenceInDays; }; export const useDateRanges = ({ defaultEndDate = null, defaultStartDate = null, defaultAdditionalDate = null, minDate = null, }: { defaultStartDate?: string | null; defaultEndDate?: string | null; defaultAdditionalDate?: string | null; minDate?: string | null; }) => { const [searchParams] = useSearchParams(); const startDateParam = searchParams.get("startDate"); const endDateParam = searchParams.get("endDate"); const minimumDate = new Date(minDate) || new Date() const [selectedDates, setSelectedDates] = React.useState<{ startDate: string; endDate: string; additionalDate?: string; }>(() => { return { startDate: defaultStartDate ?? startDateParam ?? "", endDate: defaultEndDate ?? endDateParam ?? "", additionalDate: defaultAdditionalDate ?? "", }; }); const isOutated = React.useMemo(() => { if (!selectedDates.startDate) return false; const startDate = parseStringToDate(selectedDates.startDate); return startDate < minimumDate; }, [selectedDates?.startDate, minimumDate]); const dateDifferenceInDays = useMemo(() => { if (!selectedDates.startDate || !selectedDates.endDate) return 0; return getDateDifferenceInDays({ endDate: parseStringToDate(selectedDates.endDate), startDate: parseStringToDate(selectedDates.startDate), }); }, [selectedDates.endDate, selectedDates.startDate]); return { selectedDates, setSelectedDates, minimumDate, isOutated, dateDifferenceInDays, }; }; ``` ## 9. useLocalStorage Ce hook est très pratique pour sauvegarder des informations dans le [localStorage](https://developer.mozilla.org/en-US/docs/Web/API/Window/localStorage) > Le `localStorage` est une base de donnée présente directement dans le navigateur, qui permet par exemple de sauvegarder les informations de l'utilisateur comme son thème, s'il a accepté les cookies, ou toute information utile pour améliorer l'expérience utilisateur. Cette version du hook nécessite de télécharger la librairie [usehooks-ts](https://usehooks-ts.com/). Il existe également des alternatives natives à React. ```sh Terminal npm install usehooks-ts ``` ```tsx useLocalStorage.tsx import { useCallback, useEffect, useState, type Dispatch, type SetStateAction, } from "react"; import { useEventCallback, useEventListener } from "usehooks-ts"; declare global { interface WindowEventMap { "local-storage": CustomEvent; } } type SetValue = Dispatch>; export function useLocalStorage( key: string, initialValue: T, ): [T, SetValue] { // Get from local storage then // parse stored json or return initialValue const readValue = useCallback((): T => { // Prevent build error "window is undefined" but keeps working if (typeof window === "undefined") { return initialValue; } try { const item = window.localStorage.getItem(key); return item ? (parseJSON(item) as T) : initialValue; } catch (error) { console.warn(`Error reading localStorage key “${key}”:`, error); return initialValue; } }, [initialValue, key]); // State to store our value // Pass initial state function to useState so logic is only executed once const [storedValue, setStoredValue] = useState(readValue); // Return a wrapped version of useState's setter function that ... // ... persists the new value to localStorage. const setValue: SetValue = useEventCallback((value) => { // Prevent build error "window is undefined" but keeps working if (typeof window === "undefined") { console.warn( `Tried setting localStorage key “${key}” even though environment is not a client`, ); } try { // Allow value to be a function so we have the same API as useState const newValue = value instanceof Function ? value(storedValue) : value; // Save to local storage window.localStorage.setItem(key, JSON.stringify(newValue)); // Save state setStoredValue(newValue); // We dispatch a custom event so every useLocalStorage hook are notified window.dispatchEvent(new Event("local-storage")); } catch (error) { console.warn(`Error setting localStorage key “${key}”:`, error); } }); useEffect(() => { setStoredValue(readValue()); // eslint-disable-next-line react-hooks/exhaustive-deps }, []); const handleStorageChange = useCallback( (event: StorageEvent | CustomEvent) => { if ((event as StorageEvent)?.key && (event as StorageEvent).key !== key) { return; } setStoredValue(readValue()); }, [key, readValue], ); // this only works for other documents, not the current one useEventListener("storage", handleStorageChange); // this is a custom event, triggered in writeValueToLocalStorage // See: useLocalStorage() useEventListener("local-storage", handleStorageChange); return [storedValue, setValue]; } // A wrapper for "JSON.parse()"" to support "undefined" value function parseJSON(value: string | null): T | undefined { try { // @ts-ignore return value === "undefined" ? undefined : JSON.parse(value ?? ""); } catch { return undefined; } } ``` ## 10. useQueryState Ce hook s'utilise comme [useState](https://react.dev/reference/react/useState), mais va sauvegarder les valeurs comme [paramètres d'URL](https://fr.wikipedia.org/wiki/Cha%C3%AEne_de_requ%C3%AAte). ![Exemple de paramètres d'URL](https://algomax-public.s3.eu-west-3.amazonaws.com/what_are_url_parameters_1cd183d8b2.png) Dans quel cas vas-tu utiliser les `paramètres d'URL` ? - pour sauvegarder les filtres sur une application de réservation comme [leboncoin](https://www.leboncoin.fr) ou [Airbnb](https://www.airbnb.com). - pour la pagination d'un blog (numéro de page sélectionné, limite d'articles affichés). - pour sauvegarder la valeur d'une barre de recherche (comme sur [Google](https://www.google.com) par exemple) Pour ce faire, je te présente la librairie [nuqs](https://nuqs.47ng.com), qui vient exploiter les hooks natifs à Remix (comme [useSearchParams](https://api.reactrouter.com/v7/functions/react_router.useSearchParams.html)) L'exemple le plus simple se trouve sur la documentation de [nuqs](https://nuqs.47ng.com/docs/basic-usage) ```tsx Demo.tsx import { useQueryState } from 'nuqs' export function Demo() { const [name, setName] = useQueryState('name') return ( <> setName(e.target.value)} />

Hello, {name || 'anonymous visitor'}!

) } ``` L'avantage de ce hook est sa simplicité d'utilisation. L'auteur de la librairie, [François Best](https://x.com/fortysevenfx) nous propose une **expérience développeur** d'exception. Ses nombreux `parsers` permettent de valider tout type de donnée (full typesafe) : - `parseAsString` (les paramètres sont des *string* par défaut) - `parseAsInteger` pour les entiers - `parseAsFloat` pour les chiffres à 2 décimales - `parseAsBoolean` pour les booléens - `parseAsStringLiteral` pour les *string literals* - et bien plus (les dates, les valeurs hexadécimales, les *enums* ...) Le hook **useQueryState** prend comme premier argument le nom du `paramètre d'URL`. Le deuxième argument est optionel, et peut soit être le `parser`, soit un objet de configuration : ```tsx useQueryState.tsx import { useQueryState, parseAsInteger } from 'nuqs' const [search] = useQueryState('search', { defaultValue: '' }) // ^? string const [count] = useQueryState('count', parseAsInteger) // ^? number | null -> no default value = nullable const [count2] = useQueryState('count', parseAsInteger.withDefault(0)) // ^? number ``` > J'ai de nombreux paramètres d'URL différents à gérer, comment faire ? Utilise le hook [useQueryStates](https://nuqs.47ng.com/docs/batching) (au pluriel), pour gérer un objet de plusieurs `paramètres d'URL`. ```tsx import { useQueryStates, parseAsFloat } from 'nuqs' const [{ latitude, longitude }, setCoordinates] = useQueryStates( { // Use variable names that make sense in your codebase latitude: parseAsFloat.withDefault(45.18), longitude: parseAsFloat.withDefault(5.72) }, { urlKeys: { // And remap them to shorter keys in the URL latitude: 'lat', longitude: 'lng' } } ) // No changes in the setter API, but the keys are remapped to: // ?lat=45.18&lng=5.72 setCoordinates({ latitude: 45.18, longitude: 5.72 }) ``` J'espère que ces hooks vous seront utiles ! --- ## Comment créer une API avec plusieurs actions dans Remix ? URL: https://algomax.fr/blog/comment-creer-une-api-avec-plusieurs-actions-dans-remix Publié le : 2024-06-28 Description : Améliore ton code en utilisant le concept Discriminated Union Type dans ton application Remix, avec Zod et Conform ! Il y a quelques semaines, j'ai découvert un nouveau concept Typescript en lisant un article intéressant sur les [Discriminated Union Types](https://www.hexa-web.fr/blog/discriminated-union-type-typescript) (merci encore [Dimitri](https://www.linkedin.com/in/dimitri-dumont/) 😉). Il m'a permis d'améliorer le code de mes applications **Remix**. Notamment sur la partie **serveur**, avec les **actions**. ## Pourquoi utiliser le Discriminated Union Type ? Je l'utilise parce qu'il me permet d'écrire une logique une seule fois. Au lieu de devoir écrire plusieurs fois la même logique de validation, pour des actions mineures comme la **suppression**, l'**édition** et la **création** d'une donnée, toute cette logique se retrouve dans le même fichier (et non pas dans 3-4 fichiers différents). ## Comment créer une route API Pour mieux comprendre le [routing dans Remix](/blog/les-6-routes-a-connaitre-avec-le-framework-remix-framework-react), je vous conseille l'article sur [les 6 types de routes à connaître dans Remix](/blog/les-6-routes-a-connaitre-avec-le-framework-remix-framework-react). Il nous suffit de créer un fichier dans le dossier `app/routes`, que nous allons nommer et qui prendra l'extension `tsx`. Prenons par exemple une route que nous allons appeler `actions`, qui sera accessible à l'URL `http://localhost:3000/actions`. Ensuite, nous avons besoin d'exporter une *méthode* nommée *action* (qui contient la logique **serveur**) : ```tsx app/routes/actions.tsx export const action = async ({ request }: ActionFunctionArgs) => { return null; ``` La fonction **action** sera exécutée à chaque requête API de type *POST*, *PUT*, *DELETE* ... Toutes les [méthodes HTTP](https://developer.mozilla.org/fr/docs/Web/HTTP/Methods) sauf le *GET*. Maintenant, nous allons rajouter un peu de logique, avec plusieurs actions possibles. ## Comment déterminer l'action à exécuter ? Dans cet exemple, nous souhaitons appeler cette *route* pour **ajouter** ou **supprimer** un utilisateur. Nous avons donc 2 **mutations** (ou actions) différentes dans la même *méthode* *action*. Pour faire simple, nous allons soumettre une valeur dans le formulaire qui va changer en fonction de l'action à effectuer. Nous allons ensuite utiliser un **switch** pour déterminer laquelle des deux actions doit être exécutée. > C'est la valeur de la variable *intent* qui détermine quelle logique exécuter. ```tsx app/routes/actions.tsx const createUser = async () => { } const deleteUser = async () => { } export const action = async ({ request }: ActionFunctionArgs) => { const intent : 'create' | 'delete' = 'create'; switch (intent) { case 'create': { return await createUser() } case 'delete': { return await deleteUser() } } }; ``` Cependant, c'est le composant React côté client qui va déterminer la valeur de la constante nommée **intent**. (Nous allons supprimer la déclaration de la variable *intent* dans la méthode *action*). Ajoutons la logique côté client, en exportant par défaut un composant React (je te conseille [cet article dans lequel on implémente un formulaire full typesafe avec Remix](/blog/videos/formulaires-surpuissants-avec-remix-zod-et-conform) : ```tsx app/routes/actions.tsx import type { ActionFunctionArgs } from "@remix-run/node"; import { Form, json } from "@remix-run/react"; const createUser = async () => { }; const deleteUser = async () => { }; export const action = async ({ request }: ActionFunctionArgs) => { const formData = await request.formData(); const intent = formData.get('intent') as 'create' | 'delete'; switch (intent) { case "create": { return await createUser(); } case "delete": { return await deleteUser(); } } }; export default function User() { return (
); } ``` > Mais je comprend pas, il est où ton Discriminated Union Type ? Effectivement, nous y venons. Nous avons codé toute la logique serveur et client pour nous permettre d'effectuer deux mutations au sein du même composant : **créer** et **supprimer** un utilisateur. Mais nous n'utilisons pas encore de Discriminated Union Type. On pourrait définir des types avec **Typescript** directement dans notre action, mais ça ne serait pas vraiment typesafe. Pour être sûr d'avoir des données typées, nous avons besoin d'utiliser la librairie **Zod** pour valider les données de formulaire. Je vous recommende également la librairie **Conform** pour améliorer l'expérience de vos utilisateurs. Pour [maîtriser](https://youtu.be/_-ZOGj80TMw) deux ces librairies avec Remix, [regardez cette vidéo](https://youtu.be/_-ZOGj80TMw) ## Utiliser le Discriminated Union Type avec Zod et Conform Nous avons besoin d'installer trois librairies pour avoir des données typées (grâce à Zod), discriminer la mutation (grâce à Typescript) et améliorer l'UX du formulaire (grâce à Conform). ```sh Terminal npm install zod @conform-to/zod @conform-to/react ``` Ensuite, nous devons définir deux schémas Zod : - Un schéma pour créer l'utilisateur (*CreateAction*) - Un schéma pour supprimer l'utilisateur (*DeleteAction*) Chacun de ces schémas possède une *clé* en commun : la propriété **intent**, qui nous permettra de discriminer le schéma (savoir lequel des deux représente la donnée soumise par le formulaire) Le code ressemble maintenant à ça : ```tsx app/routes/actions.tsx import { parseWithZod } from "@conform-to/zod"; import type { ActionFunctionArgs } from "@remix-run/node"; import { Form, json } from "@remix-run/react"; import { z } from "zod"; const createUser = async () => { }; const deleteUser = async () => { }; const DeleteAction = z.object({ userId: z.string({ required_error: "User ID is required", }), intent: z.literal("delete"), }); const CreateAction = z.object({ firstname: z.string({ required_error: "Firstname is required" }), intent: z.literal("create"), }); const Actions = z.union([DeleteAction, CreateAction]); export const action = async ({ request }: ActionFunctionArgs) => { const formData = await request.formData(); const submission = parseWithZod(formData, { schema: Actions, }); if (submission.status !== "success") { return json({ result: submission.reply() }); } const { intent } = submission.value; switch (intent) { case "create": { return await createUser(); } case "delete": { return await deleteUser(); } } }; export default function User() { return (
); } ``` Ce qu'il faut regarder, c'est la déclaration du schéma **Actions** : `const Actions = z.union([DeleteAction, CreateAction]);` Nous utilisons **z.union**, pour définir nos deux actions différentes en informant Zod qu'elles pourront être discriminées par la propriété *intent*. Maintenant, si l'utilisateur soumet le formulaire avec l'intention de créer un utilisateur, Zod va valider les propriétés *firstname*, *lastname* et *intent="create"*. Si l'utilisateur a l'intention de supprimer l'utilisateur, Zod va valider la propriété *intent="delete"*, et ne va pas causer d'erreur si les propriétés *firstname* et *lastname* sont absentes. Qu'en as-tu pensé ? N'hésite pas à donner ton avis sur [LinkedIn](/linkedin) ou la [chaîne YouTube](/youtube). --- ## Comment gérer les erreurs avec Remix ? (ErrorBoundary) URL: https://algomax.fr/blog/comment-gerer-les-erreurs-avec-remix-error-boundary Publié le : 2024-05-02 Description : Avoir des erreurs Javascript ne fait jamais plaisir. Mais il existe le composant ErrorBoundary). Dans ce guide, tu vas découvrir comment afficher un composant d'erreur personnalisé en pour protéger toutes les pages de ton application. As-tu déjà eu des erreurs Javascript en production ? **Pire** encore, as-tu reçu l'appel d'un client, qui se plaint d'avoir reçu un message d'erreur ? Tu perds de la crédibilité. Heureusement, il existe le composant _ErrorBoundary_ qui permet d'afficher un composant d'erreur, respectant le thème du site et ton Design System. ## Avant d'utiliser ErrorBoundary Tu retrouves un message d'erreur générique incompréhensible. Difficile de comprendre ce qui a pu se passer, et tu vas prendre du temps à réparer le bug. De plus, ton site est inutilisable en l'état. La navigation de ton utilisateur a été coupée brutalement. ![Erreur générique Javascript](https://algomax-public.s3.eu-west-3.amazonaws.com/3_Ul0_S_e9785a9f36.png) ## Après avoir mis en place ErrorBoundary Tu améliores l'expérience utilisateur. Tu réduis l'impact de l'erreur à l'endroit où elle a été déclenchée. Cela permet au développeur de vite résoudre le problème, car il sait exactement de quel fichier il s'agit. Dans Remix, on utilise le composant [ErrorBoundary](https://remix.run/docs/en/main/route/error-boundary), qui va remplacer le composant ayant déclenché l'erreur. ![Message d'erreur Remix localisé, clair et concis, ne perturbant pas le parcours utilisateur](https://algomax-public.s3.eu-west-3.amazonaws.com/error_boundary_cdcf793439.png) Tu retrouves cet exemple et davantage d'information dans la documentation de Remix concernant [l'error handling](https://remix.run/docs/en/main/guides/errors) Pour améliorer l'expérience utilisateur (UX), il est recommandé d'offrir une explication claire dans le message d'erreur, comme expliqué dans la figure ci-dessous ([Source](https://www.linkedin.com/pulse/designing-better-error-messages-ux-vitaly-friedman/)). ![Erreur Javascript personnalisée, rassurant le client et expliquant ce qui s'est passé](https://algomax-public.s3.eu-west-3.amazonaws.com/1692716312806_e0b0f10037.png) Un message d'erreur idéal : - **rassure** le client - **explique** la raison du problème - **offre** une marche à suivre pour arranger les choses (contacter le support) ## Qu'est-ce que le composant ErrorBoundary ? C'est une _librairie_ Javascript, disponible sur _NPM_ sous le nom de [react-error-boundary](https://www.npmjs.com/package/react-error-boundary). Elle est téléchargée plus de 3,7 millions de fois par semaine. Pour l'utiliser dans une application React standard, il suffit de la télécharger dans ton projet : ```bash Terminal npm install react-error-boundary ``` Ensuite, tu l'utilises dans un composant React. Elle va _englober_ le composant qui risque de déclencher une erreur, et afficher un composant _fallback_ à la place. ```tsx example.tsx import { ErrorBoundary } from 'react-error-boundary'; Something went wrong}> ; ``` Cet exemple montre deux composants : - Le composant parent _ErrorBoundary_, qui prend un _children_ (le composant enfant) et une propriété _fallback_ (affichant le composant d'erreur) - Le composant enfant _ExampleApplication_. En cas d'erreur de ce dernier, l'erreur ne va pas remonter à la racine de l'application. À la place, l'erreur va afficher le composant _fallback_. Il y a une deuxième manière d'utiliser ce composant, offrant plus de contrôle et une meilleure UX. ```tsx example.tsx import { ErrorBoundary } from 'react-error-boundary'; function fallbackRender({ error, resetErrorBoundary }) { // Call resetErrorBoundary() to reset the error boundary and retry the render. return (

Something went wrong:

{error.message}
); } { // Reset the state of your app so the error doesn't happen again }} > ; ``` La propriété _fallbackRender_ accepte une fonction fléchée, nous permettant de récupérer deux arguments : - Les informations sur l'erreur qui a été déclenchée - Une fonction permettant de ré-effectuer un rendu du composant. Déclencher cette fonction permet d'annuler l'erreur, et d'afficher le composant enfant. Généralement, on laisse l'utilisateur appeler cette méthode `resetErrorBoundary`. Plus haut, par exemple en utilisant le bouton _Try Again_. Mais cet article ne se concentre pas sur ce composant très utile. Si tu utilises [Remix](https://remix.run), tu n'as même pas besoin de l'utiliser. Il est intégré directement dans la librairie ! ## Comment gérer tes erreurs avec Remix Pour déclencher une erreur dans ton application Remix, il te suffit d'ajouter l'instruction `throw new Error('bam')` sur n'importe quelle route active. Ce qui affiche ceci : ![Une erreur dans une application Remix](https://algomax-public.s3.eu-west-3.amazonaws.com/image_19_c7ce872c07.png) Cette erreur n'est pas claire du tout. Et elle rend ton application inutilisable pour les clients : Ils ne peuvent pas accéder à une autre page depuis l'interface. De plus, cela ne t'aide pas à connaître la raison de l'erreur : elle pourrait être déclenchée par n'importe quoi. Comment faire ? Il suffit d' **exporter un composant nommé ErrorBoundary** dans ton application Remix. Commence par l'importer dans le fichier `root.tsx`, se situant dans le dossier `app/routes` de ton projet Remix. ## Le composant ErrorBoundary (Remix) Le composant _ErrorBoundary_ est une convention de Remix (au même titre que les méthodes _loader_ et _action_). Exporter un composant nommé "ErrorBoundary" dans n'importe quelle route indique à Remix qu'en cas d'erreur, il doit afficher son contenu, et ne pas propager l'erreur plus haut. Prenons par exemple l'export ci-dessous : ```tsx app/routes/root.tsx export function ErrorBoundary() { const error = useRouteError(); let errorMessage = 'Une erreur inattendue est survenue'; if (error instanceof Error) { errorMessage = error.message; } return
{errorMessage}; } ``` Après avoir ajouté ces quelques lignes, notre application ressemble à ça : ![Notre application Remix affiche le message d'erreur "bam"](https://algomax-public.s3.eu-west-3.amazonaws.com/image_20_66ae48cf4e.png) On avait rajouté la ligne `throw new Error('bam');`. Au lieu d'afficher l'erreur en rouge, sans design, notre composant _ErrorBoundary_ est affiché. Cela nous apporte quelques bénéfices : - L'erreur ne se propage pas au dessus (on y revient un peu plus bas) - On peut designer notre message d'erreur, expliquer au client ce qui s'est passé, et lui indiquer la marche à suivre - En bonus, on peut sauvegarder cette erreur avec un outil comme _Sentry_, ou l'envoyer par email pour être prévenu si jamais elle est déclenchée en production. ## Les erreurs ne remontent pas [React](https://react.dev) utilise un système de composants, avec des balises imbriquées. Ce qui donne une hiérarchie avec des "parents" et des "enfants". Avec **Remix**, il est possible d'implémenter des _routes imbriquées_. Cela signifie qu'il est possible d'avoir plusieurs routes _actives_ en même temps. C'est ce que nous montre l'image, que nous avions vu au dessus : ![Message d'erreur Remix localisé, clair et concis, ne perturbant pas le parcours utilisateur](https://algomax-public.s3.eu-west-3.amazonaws.com/error_boundary_cdcf793439.png) Cette image représente une route imbriquée. Quatres routes sont actuellement actives : - La route _root_ principale. C'est notre composant d'entrée, cette route est rendue sur toutes les routes. La route _root_ affiche la barre latérale, sur le côté gauche. - La route _sales_ (on la voit comme premier segment dans l'URL) affiche le titre de la page **"Sales"**, ainsi qu'une barre de navigation horizontale. - La route _invoices_ (on retrouve son segment dans l'URL) est "enfant" de la route Sales, et affiche les statistiques globales, la barre jaune et verte ainsi que le tableau de factures - La route dynamique _102000_ (où **102000** représente une _id_ de facture) est imbriquée dans _invoices_ (encore une fois, on le constate grâce au segment d'URL final). C'est le dernier enfant de cette hiérarchie, l'enfant le plus bas. Et il est en erreur. On peut symboliser cette vue d'une autre manière : ```tsx export default function Page () { return ( ) } ``` Chaque imbrication représente un enfant dans notre composant. Et le composant **ErrorBoundary** empêche notre erreur de remonter plus haut. Ce qui est représenté par l'image ci-dessus, au final, est un message d'erreur qui a empêché une erreur déclenchée dans le composant `Invoice` de remonter plus haut. C'est un peu comme s'il s'était passé la chose suivante : ```tsx export default function Page() { return ( }> ); } ``` Remix a remplacé le composant `Invoice` par un composant `Error`, car ce fichier était protégé par une fonction ErrorBoundary. En ajoutant ce composant sur notre route imbriquée, nous améliorons considérablement l'expérience de nos utilisateurs. De plus, nos développeurs identifient plus rapidement le problème, car le composant en erreur est au plus bas dans la hiérarchie. --- ## Remplace Eslint et Prettier avec BiomeJS, un outil d'analyse de code très rapide URL: https://algomax.fr/blog/remplace-eslint-et-prettier-avec-biome-js-un-outil-d-analyse-de-code-tres-rapide Publié le : 2024-03-29 Description : Prettier et Eslint sont des outils d'analyse de code exceptionnel. Mais sont-ils obsolètes ? On le découvre ensemble en les comparant à une technologie moderne, BiomeJS qui est beaucoup plus rapide Cet article de code est inspiré de l'article de [Simon Delpechin, "Replace Eslint & prettier with BiomeJS"](https://www.simondepelchin.be/articles/replace-eslint-prettier-with-biome) ## Présentation de BiomeJS Découvre l'outil d'analyse de code BiomeJS, qui va détecter les erreurs dans ton code très rapidement. Il est développé en Rust, et va remplacer les outils [Prettier](https://prettier.io/) et [Eslint](https://eslint.org/), te permettant d'utiliser un seul fichier de configuration simplifié. Prettier et Eslint sont téléchargés plus de 33 millions de fois par semaine sur NPM. Ce sont la référence des outils d'analyse de code. Prettier est téléchargé plus de 33 millions de fois par semaines ![Prettier est téléchargé 33 millions de fois par semaine sur NPM](https://algomax-public.s3.eu-west-3.amazonaws.com/prettier_48f5e81c6c.png) Eslint est téléchargé plus de 35 millions de fois par semaine ! ![Eslint est téléchargé 35 millions de fois par semaine sur NPM](https://algomax-public.s3.eu-west-3.amazonaws.com/eslint_28be535c37.png) ## Alors pourquoi changer ? Parce que BiomeJS est plus **simple** à configurer. Si tu veux ajouter une règle spéciale dans une configuration Eslint, tu vas devoir télécharger un plugin, et l'ajouter dans le fichier au bon endroit. C'est pas déconnant d'avoir une application web avec 8 plugins Eslint. BiomeJS change la donne. **Une seule** configuration, **une seule** dépendance, et **une seule** extension. Beaucoup plus **rapide**. Découvre les suggestions que BiomeJS me fait pour améliorer le code d'un de mes projets dans cette vidéo. Ressources utilisées : - [BiomeJS](https://biomejs.dev) - [Documentation](https://biomejs.dev/guides/getting-started) - [Article de blog d'origine](https://www.simondepelchin.be/articles/replace-eslint-prettier-with-biome) --- ## Comment configurer un monorepo avec Remix, NestJS et Turborepo URL: https://algomax.fr/blog/comment-configurer-un-monorepo-avec-remix-nest-js-et-turborepo Publié le : 2024-03-25 Description : Découvrez la stack que nous utilisons chez Algomax qui nous permet de développer facilement et rapidement avec les technologies modernes : Remix et NestJS comme adapteur. En 4 ans de développement, je n'ai pas encore trouvé une stack qui me plaît. Il y a toujours un élément qui manque (une fonctionnalité, ou une limitation technique). En tant que développeur fullstack, je souhaite bénéficier du meilleur des deux mondes. Je souhaite utiliser une technologie : - simple à utiliser - qui me permet d'implémenter une fonctionnalité rapidement - qui me permet d'avoir un contrôle total sur la logique, front comme back [Remix](https://remix.run) répond à mes attentes. C'est un framework frontend qui me permet d'utiliser Javascript et [React](https://react.dev) pour créer des sites web performants et ergonomiques. Ce framework est full-stack, signifiant que tu n'as pas besoin de configurer un serveur pour ajouter une logique backend. Tu peux appeler une base de donnée, intégrer l'authentification, et plein d'autres fonctionnalités. Cependant, il n'a pas suffisamment de maturité. Il manque plein de features, comme les middleware (qui sont très utiles pour ne pas recopier la même logique de protection des routes) J'utilise donc [NestJS](https://nestjs.com) comme serveur séparé jusqu'à présent. Ce framework [Node.JS](https://nodejs.org/en) me permet d'utiliser Javascript pour configurer une base de donnée, des routes et toute la logique métier. Ensuite, j'appelle chaque route dans Remix. Mais c'est sujet à beaucoup d'**erreurs d'inattention**, ou de **perte de synchronisation**. J'informe Remix des réponses API de NestJS en déclarant un schéma [Zod](https://zod.dev/), qui peut être erroné, et générer des erreurs. Je perd donc pas mal de temps à : - déclarer des schémas Zod - réparer des bugs, erreurs d'inattention - déclarer des méthodes pour appeler mes routes MAIS c'est terminé ! J'ai découvert une stack qui me permet d'intégrer ce serveur NestJS avec Remix. Cela remplace le serveur de Remix (celui qui faisait les appels à NestJS) par le serveur NestJS, directement. Voici les avantages : - aucune duplication de code - aucun schéma zod - aucun bug de ce style à régler C'est un gain de temps énorme. Et dans cette vidéo d'une heure, je te montre comment j'ai configuré cette stack pour que tu puisses l'utiliser dans tes projets. Convaincu ? Abonne-toi pour ne rien louper Tu peux accéder au repository en [cliquant sur ce lien](https://github.com/Varkoff/remix-nestjs-monorepo) Voici le sommaire de la vidéo : - [00:00:00](https://youtu.be/yv96ar6XNnU) Introduction - [00:03:30](https://youtu.be/yv96ar6XNnU?t=210) Configuration du projet - [00:04:28](https://youtu.be/yv96ar6XNnU?t=268) Génération du projet NestJS - [00:05:16](https://youtu.be/yv96ar6XNnU?t=316) Remix Controller - [00:10:07](https://youtu.be/yv96ar6XNnU?t=607) Configuration du projet Remix - [00:17:03](https://youtu.be/yv96ar6XNnU?t=1023) Configuration du monorepo - [00:26:22](https://youtu.be/yv96ar6XNnU?t=1582) Lancer Remix depuis NestJS - [00:28:24](https://youtu.be/yv96ar6XNnU?t=1704) Configurer Typescript et Eslint - [00:34:22](https://youtu.be/yv96ar6XNnU?t=2062) Création d'une route Remix - [00:35:57](https://youtu.be/yv96ar6XNnU?t=2157) Remix Service - [00:36:57](https://youtu.be/yv96ar6XNnU?t=2217) Typer NestJS dans Remix - [00:40:00](https://youtu.be/yv96ar6XNnU?t=2400) Déclarer les modules dans Remix - [00:44:50](https://youtu.be/yv96ar6XNnU?t=2690) Configuration Turborepo - [00:59:58](https://youtu.be/yv96ar6XNnU?t=3598) Héberger le code sur Github --- ## Ces 6 nouveautés sont attendues par les développeurs ! Tailwind v4, Million Lint, Payload CMS, Tanstack, Remix ... URL: https://algomax.fr/blog/ces-6-nouveautes-vont-te-plaire-tailwind-v4-million-lint-payload-cms-tanstack-remix Publié le : 2024-03-07 Description : Beaucoup d'annonces ont été faites cette semaine, et plein d'outils intéressants vont être mis à jour. Par exemple la version 4 de Tailwind CSS qui est très attendue, avec son nouveau parser très rapide Lightning CSS (qui utilise Rust). Beaucoup d'annonces ont été faites cette semaine, et plein d'outils intéressants vont être mis à jour. - [00:00](https://youtu.be/y-hptYWZUyI?t=0) TailwindCSS v4 - [01:17](https://youtu.be/y-hptYWZUyI?t=77) Million Lint - [03:08](https://youtu.be/y-hptYWZUyI?t=188) Payload CMS v3 - [04:44](https://youtu.be/y-hptYWZUyI?t=284) Shadcn-UI nouveaux composants - [05:20](https://youtu.be/y-hptYWZUyI?t=320) TanStack Start (nouveau framework React) - [05:55](https://youtu.be/y-hptYWZUyI?t=355) Remix React Server Components (soon) ## Tailwind CSS v4 La version 4 de [Tailwind CSS](https://tailwindcss.com) qui est très attendue, avec son nouveau parser très rapide [Lightning CSS](https://github.com/lightningcss/lightningcss) (qui utilise Rust). ## Million Lint [Million Lint](https://github.com/aidenybai/million) est une nouvelle extension qui va te permettre d'optimiser ton code React. Elle est en bêta et déjà disponible ! ## Payload CMS v3 [Payload CMS](https://www.payloadcms.com) propose une version 3, entièrement intégrée à [NextJS](https://nextjs.org). Cela nous évite d'avoir à instantier un nouveau projet, uniquement pour faire un CMS. (tu l'utilises comme un plugin NextJS, côté front). ## Shadcn-UI Shadcn-UI nous propose plusieurs nouveaux composants ! ## TanStack Start [TanStack Start](https://tanstack.com) est le framework de Tanner Linsley, auteur de React-Query et de plein d'autres librairies. J'ai hâte de tester son framework full-typesafe. ## Remix - React Server Components Et enfin, Remix travaille activement sur une version des React Server Components ! --- ## Publier une Application Android : Guide Complet pour Réussir sur le Google Play Store URL: https://algomax.fr/blog/guide-pratique-pour-le-deploiement-d-une-application-mobile-sur-android Publié le : 2024-02-23 Description : Le déploiement d'une application mobile sur la plateforme Android de Google est un processus crucial pour atteindre un large public. Dans cet article, nous allons explorer les étapes nécessaires pour mettre en place une application mobile sur Android. Déployer une application sur Android est une étape cruciale pour atteindre un public mondial. Grâce à l’écosystème ouvert de Google, les développeurs disposent de nombreux outils, mais doivent aussi faire face à une grande diversité de matériels et de configurations. Dans ce guide, nous vous expliquons toutes les étapes pour publier votre application Android sur le Play Store, de la configuration initiale à la mise en ligne, en passant par les bonnes pratiques à adopter. ## Création d'un Compte Développeur Google Play Avant toute chose, créez un compte développeur sur la Google Play Console. Le coût est de 25 USD, payé une seule fois. Une fois inscrit, complétez les informations de votre profil, notamment celles liées à votre identité, votre entreprise (le cas échéant), et les politiques de confidentialité. ## Configuration de l'Environnement de Développement Téléchargez Android Studio, l’environnement officiel de développement pour Android. Assurez-vous d’avoir les dernières versions du SDK Android, de l’émulateur, et des outils de compilation. Kotlin est aujourd’hui le langage recommandé par Google, mais Java reste également pris en charge. ## Générez une Clé de Signature (Keystore) Toutes les applications Android doivent être signées numériquement avant distribution. Créez un keystore sécurisé qui vous permettra de signer vos APK ou AAB (Android App Bundle). Conservez précieusement ce fichier : il est nécessaire pour toutes les mises à jour futures de l’app. ## Développement de l'Application pour Android Développez votre app en respectant les Material Design Guidelines pour garantir une interface cohérente et intuitive. Optimisez les performances, la gestion de la mémoire, et assurez-vous que votre application reste fluide même sur des appareils d'entrée de gamme. ## Tests sur Divers Appareils Android L’un des défis majeurs d’Android est la fragmentation : multiples tailles d’écran, versions d’OS, performances matérielles... Testez votre application sur un panel varié d’appareils et utilisez des outils comme Firebase Test Lab ou l’émulateur Android pour détecter les problèmes potentiels. ## Préparation des Ressources pour le Google Play Store Avant la soumission, préparez les éléments visuels et textuels nécessaires : Icône haute résolution Captures d’écran pour chaque format d’appareil (smartphone, tablette, etc.) Vidéo de présentation (facultative mais recommandée) Titre, description courte et description longue Catégories, tags, et politique de confidentialité ## Générez et Signez le Fichier APK ou AAB Utilisez Android Studio pour générer un fichier APK signé ou, de préférence, un AAB (Android App Bundle) — format recommandé par Google. Vérifiez bien que tout est signé avec votre keystore avant la soumission. ## Soumission de l'Application sur le Google Play Console Connectez-vous à la Google Play Console, créez une nouvelle fiche application, téléversez votre APK ou AAB, ajoutez les ressources, sélectionnez les pays de diffusion, fixez les prix (ou optez pour une app gratuite), et remplissez les informations relatives à la sécurité des données. ## Passez la Revue de Google et Publiez Google examinera automatiquement (et parfois manuellement) votre application. Ce processus peut prendre quelques heures à quelques jours. Une fois validée, vous pourrez publier votre application en un clic. Des tests internes ou en bêta peuvent être effectués avant le lancement public. ## Assurez le Suivi et les Mises à Jour Après publication, surveillez : Les commentaires utilisateurs Les statistiques d’usage (taux de crash, performances, rétention…) Les notes de l’application Publiez régulièrement des mises à jour pour améliorer l’expérience, corriger les bugs, et rester compatible avec les nouvelles versions d’Android. ## Conclusion Lancer une application sur Android est une aventure technique et stratégique. En suivant ce processus étape par étape, vous mettez toutes les chances de votre côté pour réussir sur le Google Play Store et offrir une expérience optimale à vos utilisateurs. --- ## Publier une application iOS sur l'App Store : guide complet URL: https://algomax.fr/blog/guide-pratique-pour-le-deploiement-d-une-application-mobile-sur-i-os Publié le : 2024-02-23 Description : Tout ce qu'il faut savoir pour publier votre application iOS sur l'App Store en 2026. Compte développeur, soumission, validation Apple : le guide pas à pas. # Publier une application iOS sur l'App Store : guide complet Vous avez investi du temps et de l'argent dans le développement de votre application mobile. Elle est prête. Mais entre "l'app fonctionne" et "l'app est disponible sur l'App Store", il y a un parcours que beaucoup de fondateurs sous-estiment. Apple contrôle strictement ce qui entre dans son store. C'est une bonne chose pour les utilisateurs, mais cela signifie que vous devez respecter des règles précises. Ce guide vous explique chaque étape, du compte développeur à la publication effective, sans jargon technique inutile. ## Pourquoi la publication sur l'App Store est différente d'Android Sur Android (Google Play Store), la publication est relativement simple. Vous payez 25 dollars une seule fois, vous soumettez votre application, et elle est généralement disponible en quelques heures. Chez Apple, c'est un autre monde. Chaque application passe par une revue humaine. Un membre de l'équipe Apple va tester votre app, vérifier qu'elle respecte les guidelines, s'assurer qu'elle ne plante pas, et décider si elle mérite sa place sur le store. Ce processus peut prendre entre 24 heures et plusieurs jours. Et si votre app est rejetée, il faut corriger le problème puis resoumettre. Ce n'est pas un obstacle, c'est un filtre qualité. Mais il faut s'y préparer. ## Étape 1 : Créer votre compte Apple Developer Avant toute chose, vous avez besoin d'un compte développeur Apple. Il existe deux options : **Le compte individuel** coûte 99 dollars par an (environ 92 euros). Il est lié à votre nom personnel. C'est suffisant si vous êtes auto-entrepreneur ou si vous lancez un projet solo. **Le compte organisation** coûte également 99 dollars par an, mais il est lié à votre entreprise. Apple vous demandera un numéro D-U-N-S (un identifiant international d'entreprise). Si votre société n'en a pas, vous pouvez en demander un gratuitement sur le site de Dun & Bradstreet. Comptez environ 5 à 15 jours ouvrés pour l'obtenir. Notre conseil : si vous avez une société, prenez le compte organisation. Le nom de votre entreprise apparaîtra sur le store, ce qui inspire plus confiance qu'un nom de personne. L'inscription se fait sur [developer.apple.com](https://developer.apple.com). Prévoyez quelques jours pour la validation par Apple, surtout pour les comptes organisation. ## Étape 2 : Préparer votre fiche App Store Avant même de soumettre le fichier technique de votre application, vous devez créer sa fiche dans App Store Connect, la plateforme de gestion d'Apple. Voici ce qu'il faut préparer : **Le nom de l'application.** C'est celui qui apparaîtra sur le store. Il doit être unique. Si quelqu'un utilise déjà le nom que vous voulez, il faudra en trouver un autre. **Le sous-titre.** 30 caractères maximum. Utilisez-le pour expliquer brièvement ce que fait votre app. **La description.** Jusqu'à 4 000 caractères. Les trois premières lignes sont les plus importantes, car c'est ce que les utilisateurs voient avant de cliquer sur "plus". Soyez clair sur le bénéfice principal de votre application. **Les mots-clés.** 100 caractères au total pour aider Apple à référencer votre app dans les recherches. Séparez-les par des virgules, ne répétez pas les mots déjà présents dans votre titre. **Les captures d'écran.** Vous devez fournir des captures pour chaque taille d'écran supportée (iPhone 6.7 pouces, iPhone 6.1 pouces, iPad si votre app le supporte). Minimum 3 captures, maximum 10. Ce sont souvent ces images qui convainquent un utilisateur de télécharger ou non votre app. Investissez du temps là-dessus. **L'icône.** 1024 x 1024 pixels, format PNG, sans coins arrondis (Apple les arrondit automatiquement), sans transparence. **La politique de confidentialité.** Obligatoire. Vous devez fournir une URL vers une page qui explique quelles données vous collectez et comment vous les utilisez. ## Étape 3 : La soumission technique C'est la partie que votre équipe technique (ou votre prestataire) gère. Mais en tant que fondateur, voici ce que vous devez savoir. L'application est envoyée à Apple sous forme d'un "build", un fichier compilé prêt à être installé. Ce fichier est généré depuis Xcode (l'outil de développement d'Apple), puis uploadé sur App Store Connect. **Les permissions.** Si votre app utilise la caméra, le micro, la localisation ou les notifications, vous devez expliquer pourquoi à l'utilisateur via un message clair. Apple rejette systématiquement les apps dont les messages de permission sont vagues. **La connexion de test.** Si votre app nécessite un compte pour fonctionner, vous devez fournir des identifiants de test à Apple. Sans cela, le reviewer ne pourra pas tester votre application et elle sera rejetée automatiquement. ## Étape 4 : La revue Apple Une fois le build uploadé et la fiche complétée, vous soumettez l'application pour review. **Le délai moyen en 2026** est de 24 à 48 heures. Certaines périodes sont plus chargées (fin d'année notamment). Prévoyez toujours une marge dans votre planning de lancement. **Ce qu'Apple vérifie :** L'application ne plante pas. C'est basique, mais c'est la première cause de rejet. L'application fait ce qu'elle promet. Si votre fiche dit "gérez vos factures en un clic" et que l'app ne permet pas de créer de factures, c'est un rejet. L'application respecte les guidelines de design. Apple a des standards élevés en matière d'interface utilisateur. L'application respecte les règles sur les achats intégrés. Si vous vendez du contenu numérique dans votre app (abonnements, fonctionnalités premium), vous devez obligatoirement passer par le système d'achat intégré d'Apple. Apple prend une commission de 15 à 30 % sur chaque transaction. ## Les raisons de rejet les plus fréquentes Voici les motifs de rejet que nous rencontrons le plus souvent chez [nos clients](/services/creation-application-mobile) : **Bugs et crashs.** Testez rigoureusement votre app avant de soumettre. Sur différents modèles d'iPhone, avec différentes connexions réseau. **Métadonnées incomplètes ou trompeuses.** Votre description ne correspond pas à ce que fait réellement l'app. **Absence de politique de confidentialité.** Chaque application doit en avoir une. Pas d'exception. **Mauvaise gestion des permissions.** Demander l'accès à la caméra pour une app de prise de notes, sans raison valable, entraîne un rejet. **Contenu minimum insuffisant.** Apple refuse les apps qui sont essentiellement des sites web emballés dans une coquille native. Si votre app n'apporte rien de plus qu'un site mobile, elle sera rejetée. **Achats intégrés manquants.** Si vous redirigez les utilisateurs vers un site web pour payer au lieu d'utiliser le système d'Apple, c'est un rejet garanti pour le contenu numérique. ## Combien de temps prévoir au total ? | Étape | Durée estimée | |---|---| | Création du compte développeur | 1 à 7 jours | | Obtention du D-U-N-S (si organisation) | 5 à 15 jours | | Préparation de la fiche store | 2 à 5 jours | | Soumission et review Apple | 1 à 5 jours | | Corrections si rejet (le cas échéant) | 2 à 10 jours | Au total, comptez entre 2 et 5 semaines entre le moment où votre app est techniquement prête et le moment où elle est disponible sur le store. Ne planifiez jamais votre lancement public le jour de la soumission. ## Les coûts à prévoir Le compte Apple Developer revient à 99 dollars par an. C'est un abonnement : si vous ne renouvelez pas, votre app est retirée du store. Les captures d'écran professionnelles peuvent coûter entre 200 et 800 euros si vous faites appel à un graphiste. Si votre app inclut des achats intégrés, Apple prend 30 % de commission (15 % si vous gagnez moins d'un million de dollars par an via le programme Small Business). ## Après la publication **Les mises à jour.** Apple publie une nouvelle version d'iOS chaque année, en septembre. Votre app doit rester compatible. Si elle ne fonctionne plus sur la dernière version d'iOS, Apple peut la retirer du store. **Les reviews utilisateurs.** Répondez aux avis, surtout les négatifs. Cela montre que vous êtes actif et que vous vous souciez de vos utilisateurs. **L'ASO (App Store Optimization).** C'est le référencement naturel de l'App Store. Optimisez régulièrement votre titre, vos mots-clés et vos captures d'écran pour améliorer votre visibilité. ## Faut-il gérer tout cela en interne ? Si vous avez une équipe technique avec de l'expérience iOS, elle peut gérer l'ensemble du processus. Dans le cas contraire, faire appel à une agence spécialisée vous fera gagner un temps considérable, surtout pour la première publication. Chez Algomax, nous accompagnons les fondateurs dans tout le cycle de vie de leur application mobile, de la [conception](/services/creation-application-mobile) jusqu'à la publication et la maintenance. Nous avons publié des dizaines d'apps sur l'App Store et connaissons les pièges à éviter. Si vous préparez le lancement de votre app iOS, [contactez-nous](/contact) pour un accompagnement sur mesure. Nous pouvons aussi vous aider à [concevoir votre application de A à Z](/blog/guide-complet-de-la-conception-d-une-application-mobile-de-a-a-z) si vous en êtes encore à l'étape de réflexion. --- ## Comment créer une application mobile en 2026 (guide complet) URL: https://algomax.fr/blog/guide-complet-de-la-conception-d-une-application-mobile-de-a-a-z Publié le : 2024-02-23 Description : De l'idée aux stores iOS et Android : étapes, budget (8-40k€), stack technique, pièges à éviter. Par Algomax, agence mobile à Strasbourg. # Concevoir une application mobile de A à Z : le guide pour fondateurs Vous avez une idée d'application. Peut-être même plusieurs. Mais entre l'idée et l'app qui tourne sur les téléphones de vos utilisateurs, il y a un chemin que la plupart des fondateurs découvrent en marchant. Souvent avec quelques mauvaises surprises en route. Ce guide est conçu pour vous donner une vision claire de chaque étape. Pas de jargon inutile. Pas de promesses irréalistes. Juste ce que vous devez savoir pour prendre les bonnes décisions, que vous fassiez développer votre app en interne ou par un prestataire. ## Avant de coder : valider votre idée C'est l'étape que 80 % des fondateurs sautent. Et c'est aussi celle qui coûte le plus cher quand on la néglige. Avant de dépenser le moindre euro en développement, posez-vous ces questions : **Qui sont vos utilisateurs ?** Pas "tout le monde". Des personnes précises, avec un problème précis. Un livreur indépendant qui perd du temps à organiser ses tournées. Une mère de famille qui cherche des activités pour ses enfants le mercredi. Un gérant de restaurant qui veut gérer ses réservations depuis son téléphone. **Comment résolvent-ils ce problème aujourd'hui ?** S'ils utilisent déjà une solution (même imparfaite, même un tableur Excel), c'est bon signe. Cela prouve que le problème est réel. S'ils ne font rien du tout, demandez-vous pourquoi. **Sont-ils prêts à payer ?** Ou à changer leurs habitudes ? Une idée brillante ne vaut rien si personne ne l'adopte. Pour valider, vous n'avez pas besoin d'une app. Une page web simple qui décrit votre concept, avec un bouton "je suis intéressé", peut suffire. Parlez à des utilisateurs potentiels. Pas à vos amis (ils vous diront ce que vous voulez entendre), mais à de vrais prospects. ## Le design : passer de l'idée aux écrans Une fois votre idée validée, il faut la traduire en quelque chose de concret. C'est l'étape du design, qui se décompose en plusieurs phases. ### Les wireframes (maquettes fil de fer) Ce sont des schémas simples, en noir et blanc, qui montrent la structure de chaque écran. Où se trouve le bouton ? Quel est le parcours de l'utilisateur pour accomplir telle action ? On ne parle pas encore de couleurs ou de polices. On parle de logique et de navigation. Un wireframe, c'est comme le plan d'un architecte avant de construire la maison. Personne ne pose de carrelage avant d'avoir validé le plan. ### Les maquettes haute fidélité Ensuite viennent les maquettes détaillées. Couleurs, typographie, icônes, images. C'est ce qui ressemble à l'application finale. Elles sont généralement créées dans des outils comme Figma ou Sketch. À ce stade, vous devez pouvoir "naviguer" dans votre future app grâce à un prototype cliquable. Cela vous permet de tester l'expérience utilisateur avant d'écrire la moindre ligne de code. C'est le moment idéal pour montrer le projet à des utilisateurs potentiels et recueillir leurs retours. ### Le design system Pour les projets ambitieux, il est utile de créer un design system (un ensemble de règles visuelles). Comment se comportent les boutons, quelle est la palette de couleurs, comment s'affichent les messages d'erreur. Cela garantit la cohérence visuelle dans toute l'application et facilite le travail des développeurs. **Budget pour le design :** entre 2 000 et 15 000 euros selon la complexité. Un outil avec 5 écrans simples sera évidemment moins cher qu'une application avec 40 écrans, des animations et un système de chat intégré. ## Choisir la bonne technologie C'est probablement la décision technique la plus importante. Et elle a un impact direct sur votre budget et votre calendrier. ### Le développement natif Cela signifie créer deux applications séparées : une pour iPhone (en Swift, le langage d'Apple) et une pour Android (en Kotlin, le langage de Google). Chaque plateforme a son propre code, son propre design, ses propres développeurs. **Avantages :** performances optimales, accès complet à toutes les fonctionnalités du téléphone (appareil photo, Bluetooth, capteurs). **Inconvénients :** vous payez deux fois le développement. Et chaque nouvelle fonctionnalité doit être développée deux fois. **Pour qui ?** Les applications qui nécessitent des performances extrêmes (jeux 3D, réalité augmentée) ou qui exploitent des fonctionnalités très spécifiques du téléphone. ### Le développement cross-platform Ici, vous écrivez le code une seule fois et il fonctionne sur iPhone et Android. Les deux frameworks les plus utilisés en 2026 sont React Native (créé par Meta) et Flutter (créé par Google). **React Native** utilise JavaScript, le langage de programmation le plus populaire au monde. L'écosystème est mature, les développeurs sont nombreux. De grandes applications l'utilisent : Instagram, Discord, Shopify. **Flutter** utilise Dart, un langage moins connu mais très performant. L'interface est fluide et les animations sont de qualité. Des apps comme Google Pay et BMW l'utilisent. **Avantages du cross-platform :** un seul code pour deux plateformes, coûts de développement réduits de 30 à 40 %, mises à jour plus rapides. **Inconvénients :** certaines fonctionnalités très spécifiques au téléphone peuvent être plus complexes à implémenter. Les performances sont légèrement inférieures au natif, mais pour 95 % des applications, la différence est imperceptible. **Pour qui ?** La majorité des applications d'entreprise, les marketplaces, les outils de gestion. C'est l'option que nous recommandons le plus souvent chez [Algomax](/services/creation-application-mobile). Pour une comparaison détaillée, consultez notre article [React Native vs Natif : guide pour décideurs non-techniques](/blog/react-native-vs-natif-guide-pour-decideurs-non-techniques). ### Les applications hybrides / PWA Les PWA (Progressive Web Apps) sont des sites web qui se comportent comme des applications. Elles s'installent depuis le navigateur, fonctionnent hors ligne, et peuvent envoyer des notifications. **Avantages :** coût de développement le plus bas, pas de validation Apple ou Google, mises à jour instantanées. **Inconvénients :** performances limitées, accès restreint aux fonctionnalités du téléphone, pas de présence sur les stores. **Pour qui ?** Les projets avec un budget très serré, les premières versions pour tester un concept, les outils internes d'entreprise. ## Les phases de développement ### Phase 1 : Mise en place technique (1 à 2 semaines) L'équipe de développement configure l'environnement de travail. Choix des outils, mise en place du serveur, création de la base de données. C'est de la plomberie. Invisible pour vous, mais essentielle. ### Phase 2 : Développement du MVP (6 à 16 semaines) Le MVP (Minimum Viable Product, ou produit minimum viable) est la première version de votre app avec uniquement les fonctionnalités essentielles. Pas tout ce que vous imaginez. Juste ce qui est nécessaire pour que vos premiers utilisateurs puissent tester le concept. Beaucoup de fondateurs veulent tout inclure dès la version 1. C'est une erreur classique. Un MVP trop ambitieux coûte plus cher, prend plus de temps, et retarde le moment où vous obtenez des retours utilisateurs. Le développement se fait généralement en "sprints" de deux semaines (des cycles courts de travail). À la fin de chaque sprint, vous voyez une version fonctionnelle de l'app avec les nouvelles fonctionnalités. Vous pouvez donner vos retours et ajuster les priorités. ### Phase 3 : Tests (2 à 4 semaines, en parallèle) Les tests ne se font pas qu'à la fin. Il y a les tests automatisés (écrits par les développeurs), les tests manuels (quelqu'un utilise l'app et cherche les bugs), et les tests utilisateurs (de vraies personnes de votre cible essaient l'app). Ne négligez pas cette phase. Un bug qui passe en production coûte dix fois plus cher à corriger qu'un bug détecté pendant les tests. ### Phase 4 : Publication (2 à 5 semaines) La mise en ligne sur les stores Apple et Google. Chaque store a ses propres exigences. Pour iOS en particulier, la revue par Apple peut prendre du temps et nécessiter des corrections. Nous avons écrit un [guide détaillé sur la publication iOS](/blog/guide-pratique-pour-le-deploiement-d-une-application-mobile-sur-i-os) si vous voulez approfondir ce sujet. ## Combien coûte une application mobile en 2026 ? C'est la question que tout le monde pose. La réponse honnête : ça dépend. Mais voici des fourchettes réalistes pour le marché français. | Type d'application | Budget estimé | Délai | |---|---|---| | MVP simple (5-10 écrans) | 15 000 à 35 000 euros | 2 à 3 mois | | Application moyenne (15-25 écrans, API, paiement) | 35 000 à 80 000 euros | 3 à 6 mois | | Application complexe (marketplace, temps réel, IA) | 80 000 à 200 000 euros et plus | 6 à 12 mois | Ces budgets incluent le design, le développement front-end et back-end, les tests et la publication. Attention aux devis anormalement bas. Si quelqu'un vous propose une application complète pour 5 000 euros, posez-vous des questions. Économiser sur le développement initial mène presque toujours à des dépenses bien plus élevées en corrections et refonte par la suite. Pour une analyse détaillée des coûts, consultez notre guide [Combien coûte une application mobile en 2026 ?](/blog/combien-coute-une-application-mobile-en-2026) ## Les pièges à éviter **Vouloir copier une app existante en "moins cher".** "Je veux un Uber pour mon secteur" est une phrase courante. Le problème, c'est qu'Uber a investi des centaines de millions en développement. Concentrez-vous sur ce qui vous différencie. **Ne pas prévoir le budget de maintenance.** Votre app n'est pas un produit fini le jour de son lancement. Prévoyez environ 15 à 20 % du coût de développement initial par an pour la maintenance. **Changer d'avis en cours de route.** Chaque modification du périmètre en cours de développement coûte du temps et de l'argent. Plus vous êtes clair sur vos besoins au départ, moins le projet dérapera. **Ignorer les retours utilisateurs.** Vous n'êtes pas votre utilisateur. Faites tester votre app à des personnes qui ne connaissent pas votre projet. Observez-les sans les guider. **Oublier le back-office.** Votre app a besoin d'un panneau d'administration pour gérer les utilisateurs, le contenu, les données. Beaucoup de fondateurs ne pensent qu'à l'app visible par le client final. ## Par où commencer ? Mettez votre idée par écrit. Pas un document de 50 pages. Juste les réponses aux questions fondamentales : quel problème résolvez-vous, pour qui, et comment votre app sera différente de ce qui existe. Parlez à 10 utilisateurs potentiels. Pas par email. Par téléphone ou en face-à-face. Écoutez plus que vous ne parlez. Demandez des devis à 2 ou 3 prestataires. Comparez non seulement les prix, mais la méthodologie, la réactivité et la qualité du dialogue. Chez Algomax, nous accompagnons les fondateurs dès la phase de réflexion. Que vous ayez une idée sur un coin de table ou un cahier des charges détaillé, nous pouvons vous aider à définir le bon périmètre, choisir la bonne technologie et construire une application qui répond vraiment aux besoins de vos utilisateurs. [Prenez contact avec notre équipe](/contact) pour discuter de votre projet. Le premier échange est toujours gratuit et sans engagement. --- ## Héberge des fichiers avec Remix URL: https://algomax.fr/blog/heberge-des-fichiers-avec-remix Publié le : 2024-02-22 Description : Comment implémenter l'hébergement de fichiers avec le framework Remix ? On implémente ensemble un formulaire 'POST' pour y arriver. Dans cet article, nous allons implémenter ensemble un [formulaire](/blog/implemente-ton-premier-formulaire-avec-remix-full-typesafe-ux-friendly) permettant d'héberger des fichiers (images, vidéos, PDFs...). Nous utilisons le framework [Remix](https://remix.run) et son [puissant système de routing](/blog/les-6-routes-a-connaitre-avec-le-framework-remix-framework-react) pour y parvenir. Vous pouvez aussi consulter ce [guide au format vidéo](https://youtu.be/c7nLBwfg_K8) sur YouTube. Voici la commande pour initialiser un nouveau projet Remix : ```bash npx create-remix@latest ``` ## Comment héberger un formulaire avec Remix ? On a besoin de trois éléments : - un fichier à héberger - un `input` de type `file` pour le sélectionner et l'envoyer au serveur - un serveur pour le sauvegarder et le *servir* sur une route ### Un fichier à héberger Voici une image. Je vous laisse la [télécharger](https://unsplash.com/fr/photos/disque-vinyle-noir-et-blanc-hrUhyFq6u-A). C'est le document que nous allons héberger ensemble. ![un vinyle, l'emoji utilisé par l'équipe de développement de Remix](https://algomax-public.s3.eu-west-3.amazonaws.com/brett_jordan_hr_Uhy_Fq6u_A_unsplash_3698c66818.jpg) ### Un input de type file pour envoyer le fichier au serveur Nous allons ajouter un fichier dans le dossier `app/routes`, nommé `file`. Dedans, nous allons exporter par défaut un composant React (ce sera notre vue). ```tsx app/routes/file.tsx import { Form } from '@remix-run/react'; export function File() { return (
); } ``` Notez l'utilisation du composant [Form](https://remix.run/docs/en/main/components/form) de Remix. Bien que l'hébergement des fichiers fonctionne avec un [formulaire classique](https://developer.mozilla.org/fr/docs/Web/HTML/Element/form), il est recommendé de l'utiliser. ### Un serveur pour sauvegarder le fichier et le servir aux utilisateurs Dans l'article [6 Routes à connaître si tu utilises Remix (guide complet)](/blog/les-6-routes-a-connaitre-avec-le-framework-remix-framework-react), nous avons vu ensemble qu'il nous suffit d'ajouter une fonction à notre fichier pour ajouter une logique côté serveur. Comme le formulaire effectue un `POST`, nous allons ajouter une fonction nommée [action](https://remix.run/docs/en/main/route/action) dans notre composant, et nous allons l'exporter. ```tsx app/routes/file.tsx focus=1,4:7 import type { ActionFunctionArgs } from '@remix-run/node'; import { Form } from '@remix-run/react'; export const action = async ({ request }: ActionFunctionArgs) => { // Nous devons sauvegarder le fichier à cet endroit return null; }; export function File() { return (
); } ``` Il ne nous reste plus qu'à coder la logique dans notre `action` et nous avons terminé ! N'est-ce pas ? > Pas vraiment. Avez-vous entendu parlé de la propriété `encType` ? ## La propriété de formulaire 'encType' ### Version courte Il faut rajouter la propriété `encType` à notre formulaire. ```tsx app/routes/file.tsx mark=13[4:42] import type { ActionFunctionArgs } from '@remix-run/node'; import { Form } from '@remix-run/react'; export const action = async ({ request }: ActionFunctionArgs) => { // Nous devons sauvegarder le fichier à cet endroit return null; }; export function File() { return (
); } ``` ### Pourquoi rajouter la propriété encType ? Je ne connaissais pas cette propriété avant d'en avoir besoin. Par défaut, la propriété [encType](https://developer.mozilla.org/fr/docs/Web/API/HTMLFormElement/enctype) (ou type d'encodage) prend comme valeur `application/x-www-form-urlencoded`. Mais il en existe deux autres. Voici la [définition sur MDN](https://developer.mozilla.org/fr/docs/Web/HTML/Element/form#enctype) > Lorsque la valeur de l'attribut method est post, cet attribut définit le [type MIME](https://fr.wikipedia.org/wiki/Type_de_m%C3%A9dias) qui sera utilisé pour encoder les données envoyées au serveur. C'est un attribut énuméré qui peut prendre les valeurs suivantes : - `application/x-www-form-urlencoded`: la valeur par défaut si l'attribut n'est pas défini - `multipart/form-data` : la valeur utilisée par un élément [input](https://developer.mozilla.org/fr/docs/Web/HTML/Element/input) avec l'attribut type="file". - `text/plain`, correspondant au [type MIME](https://fr.wikipedia.org/wiki/Type_de_m%C3%A9dias) éponyme et utilisé à des fins de débogage. Nous utilisons un `input` de type `file`. Nous avons donc besoin de rajouter la propriété `encType='multipart/form-data'` pour envoyer notre fichier au format binaire. Nous avons terminé l'implémentation côté client ! Le reste se passe côté serveur. ## Sauvegarder un fichier côté serveur Pour pouvoir sauvegarder notre fichier et la servir à nos utilisateurs, nous allons devoir - l'extraire du [FormData](https://developer.mozilla.org/en-US/docs/Web/API/FormData) avec les API de Remix [ unstable_createFileUploadHandler](https://remix.run/docs/en/main/utils/unstable-create-file-upload-handler) et [ unstable_parseMultipartFormData](https://remix.run/docs/en/main/utils/parse-multipart-form-data#unstable_parsemultipartformdata) - (Bonus) Valider le `formData` avec Zod et Conform - (Bonus) Renommer le fichier et lui donner un identifiant unique - Servir le fichier aux utilisateurs (le rendre disponible à l'URL `localhost:3000/files/image.png` ### Extraire le fichier depuis le FormData Nous souhaitons conserver le document sur notre serveur. Pour ce faire, nous allons utiliser la méthode [ unstable_createFileUploadHandler](https://remix.run/docs/en/main/utils/unstable-create-file-upload-handler). Cette méthode prend un objet d'options en argument. Voici les options que nous allons utiliser : - `maxPartSize` pour définir la taille max du fichier en bytes. - `directory` pour définir le dossier de sauvegarde du document ```tsx app/routes/file.tsx focus=2:3,9:17 import { unstable_createFileUploadHandler, unstable_parseMultipartFormData, type ActionFunctionArgs, } from '@remix-run/node'; import { Form } from '@remix-run/react'; export const action = async ({ request }: ActionFunctionArgs) => { const formData = await unstable_parseMultipartFormData( request, unstable_createFileUploadHandler({ maxPartSize: 1024 * 1024 * 10, // 10MB directory: './uploads', }) ); const file = formData.get('file') as File; // 👈 notre fichier au format Buffer console.log(file.name); // 👈 Le nom du fichier pour pouvoir le retrouver sur le serveur return null; }; export function File() { return (
); } ``` ### Enregistrer le fichier sur le disque dur serveur Au moment de récupérer le fichier, ligne `16`, le fichier a déjà été enregistré dans le dossier `uploads`. Pour avoir plus de contrôle sur la sauvegarde de ce fichier, je préfère utiliser la méthode [ unstable_createMemoryUploadHandler](https://remix.run/docs/en/main/utils/unstable-create-memory-upload-handler). Cela nous permet d'enregistrer nous-même le fichier récupéré ligne `17` (on peut ensuite l'envoyer sur AWS S3 ou un autre service ...) ```tsx app/routes/file.tsx focus=1:20 import { unstable_createMemoryUploadHandler, unstable_parseMultipartFormData, type ActionFunctionArgs, } from '@remix-run/node'; import { Form } from '@remix-run/react'; import { saveVideoToLocal } from '~/videos.server'; export const action = async ({ request }: ActionFunctionArgs) => { const formData = await unstable_parseMultipartFormData( request, unstable_createMemoryUploadHandler({ maxPartSize: 1024 * 1024 * 10, // 10MB }) ); const file = formData.get('file') as File; // 👈 notre fichier au format Buffer console.log(file.name); // 👈 Le nom du fichier pour pouvoir le retrouver sur le serveur // mark const { name } = await saveVideoToLocal({ videoFile: file }); // 👈 On sauvegarde le fichier sur le serveur return { name }; }; export function File() { return (
); } ``` ```ts videos.server.ts export const saveVideoToLocal = async ({ videoFile }: { videoFile: File }) => { const originalName = new Date().toISOString() + videoFile.name; const baseDirectory = join(process.cwd(), './uploads'); const filePath = join(baseDirectory, originalName); const arrayBuffer = await videoFile.arrayBuffer(); const arrayBufferView = new Uint8Array(arrayBuffer); const fileExists = checkIfFileExists({ filePath, }); if (fileExists) { throw new Error('Le fichier existe déjà ...'); } await access(baseDirectory); await writeFile(filePath, arrayBufferView); return { name: originalName }; }; ``` ### Servir le fichier aux utilisateurs Pour rendre accessible nos fichiers hébergés (par exemple à l'URL `localhost:3000/file/image.jpeg`, nous avons besoin de : - Créer une **nouvelle route** - Vérifier que le fichier **existe** - Le renvoyer en fonction de son **mimetype** (si c'est un *JPEG*, la réponse sera différente par rapport au format *mp4*) Nous allons créer un nouveau fichier nommé `file.$filename.tsx` dans le dossier `app/routes`. Pour ce faire, nous devons également installer la librairie [mime](https://npmjs.com/package/mime). Les autres librairies `fs` et `path` sont natives à l'environnement NodeJS. ```tsx app/routes/file.$filename.tsx import { LoaderFunctionArgs } from '@remix-run/node'; import { readFileSync } from 'fs'; import mime from 'mime'; import { join } from 'path'; export const loader = async ({ params }: LoaderFunctionArgs) => { const filename = params.filename; if (!filename) { // 👈 On vérifie que le nom du fichier est bien fourni throw new Error('No filename provided'); } const filePath = join(process.cwd(), './uploads', filename); // 👈 On construit le chemin absolu du fichier const fileContent = readFileSync(filePath); // 👈 On lit le fichier const mimeType = mime.getType(filePath); // 👈 On récupère le type MIME du fichier console.log({ mimeType, filename, filePath, fileContent }); return new Response(fileContent, { // 👈 On renvoie le fichier headers: { 'Content-Type': mimeType || 'application/octet-stream', // 👈 On renvoie le type MIME du fichier, }, }); }; ``` ## Conclusion Conclusion Dans cet article, nous avons vu comment implémenter un formulaire d'upload de fichiers dans Remix. Nous avons utilisé le composant [Form](https://remix.run/docs/en/main/components/form) de Remix et les API unstable_createFileUploadHandler et unstable_parseMultipartFormData pour gérer le transfert de fichiers. Nous avons également vu comment sauvegarder les fichiers sur le serveur et les servir aux utilisateurs. --- ## Implémente ton premier formulaire avec Remix (full typesafe, UX friendly) URL: https://algomax.fr/blog/implemente-ton-premier-formulaire-avec-remix-full-typesafe-ux-friendly Publié le : 2024-02-17 Description : Dans cet article, nous allons implémenter un formulaire basique en React, puis nous l'améliorons avec une validation côté serveur grâce aux librairies Zod et Conform pour offrir une UX (expérience utilisateur) excellente. Votre lead dev vous demande d'améliorer l'UX du formulaire de contact pour qu'il soit plus explicite dans l'affichage de ses erreurs. Il est vrai que l'UX est importante, même en tant que développeur. J'aime personnellement savoir quel champ a posé problème lorsque j'envoie un formulaire. Et les utilisateurs aussi : ils peuvent gagner en autonomie et nous expliquer l'erreur qu'ils ont rencontré. Dans cet article, nous allons implémenter étape par étape un formulaire avec le framework [Remix](https://remix.run). D'abord sans librairie externe. Puis nous allons l'améliorer peu à peu en ajoutant [Zod](https://zod.dev/), puis [Conform](https://conform.guide/). Cet article existe également au [format vidéo](https://youtu.be/_-ZOGj80TMw) sur YouTube. Commençons par faire simple. ## Implémentation d'un formulaire basique avec Remix Avant d'installer quoi que ce soit, nous allons implémenter un formulaire HTML basique. Nous allons d'abord : - instantier un nouveau projet Remix avec la commande `npx create-remix@latest` - `npm install` pour installer les dépendances - `npm run dev` pour lancer le serveur de développement Ensuite, nous allons supprimer le contenu du fichier `app/routes/_index.tsx` et le remplacer par un formulaire *simple*. ```tsx app/routes/_index.tsx export default function Index() { return (
); } ``` Actuellement, nous avons implémenté un formulaire HTML qui contient un `input` et un `button`. Il ne nous sera pas très utile dans cet état. Ce formulaire utilise la méthode *GET* par défaut. Cela signifie que chacune des données présente dans l'[input](https://developer.mozilla.org/en-US/docs/Web/HTML/Element/input) seront visibles dans l'URL lors de la soumission (sous forme de [paramètres d'URL](https://developer.mozilla.org/fr/docs/Web/API/URLSearchParams)). De plus, l'`input` ne possède pas de propriété [`name`](https://developer.mozilla.org/en-US/docs/Web/HTML/Element/input#name). Sa valeur ne sera pas récupérée. Elle a besoin d'avoir un nom pour être identifiée. (comme la paire clé-valeur dans un *object*) Cet article va uniquement utiliser un formulaire [POST](https://developer.mozilla.org/fr/docs/Web/HTTP/Methods/POST), qui est idéal pour envoyer des données sensibles comme des adresses email. ### Rajoutons des attributs 'form.POST' et 'input.name' Il manque des attributs à notre formulaire: - la méthode `POST` de notre formulaire JSX - la propriété `name` à notre `input` (qui prend également la valeur *name* ```tsx app/routes/_index.tsx focus=3[9:21],4[23:33],5[12:24] export default function Index() { return (
); } ``` Essayons de soumettre notre formulaire ! ![soumission de formulaire échouée](https://algomax-public.s3.eu-west-3.amazonaws.com/failed_submission_402df7004f.gif) ### 405 Method Not Allowed L'erreur `405 Method Not Allowed` apparaît. Mais nous n'avons pas fait d'erreur au niveau de l'implémentation du formulaire. Cette erreur nous explique qu'il faut maintenant ouvrir un *API endpoint* à cette *URL*. Ce que j'appelle *API endpoint* est en réalité une déclaration de route *API*, comme avec Express. La page [API Routes](https://remix.run/docs/en/main/guides/api-routes#api-routes) (documentation de Remix) nous explique que les fichiers de type route (dans le dossier `routes`) sont leur propre API. Pour mieux comprendre, regardons la page [Fullstack Data Flow](https://remix.run/docs/en/main/guides/api-routes#api-routes) de la doc. ![Lifecycle Remix - Loader, Component, Action](https://algomax-public.s3.eu-west-3.amazonaws.com/loader_action_component_a52cbe146c.png) Le schéma ci-dessus représente l'ordre d'exécution des méthodes de Remix : - La méthode `loader` (facultative) s'éxecute en premier lors d'un chargement de page. Exécuté **côté serveur**, on peut charger les données nécessaires avant d'afficher la vue. Pratique pour implémenter le *SSR* et très pratique pour le **SEO**. - Le composant [React](https://fr.react.dev/) exporté **par défaut** représente la vue. Il s'éxecute à la fin de la méthode `loader`. Ce composant est exécuté côté serveur puis **côté client**. C'est dedans qu'on va ajouter nos formulaires, nos states (*useState*, *useEffect*, etc ...) - La méthode `action` (facultative) s'éxecute **seulement** si une soumission de formulaire **POST** est effectuée dans la route. Cette méthode contient toute la logique liée à notre mutation (se connecter, s'inscrire, modifier une donnée en DB ...) et va s'exécuter **côté serveur**. > 405 Method Not Allowed signifie qu'on effectue un **POST** sur notre route, mais qu'on a oublié d'implémenter la logique **serveur** (on doit déclarer une méthode `action`) ### Ajout de la méthode 'action' La fonction [action](https://remix.run/docs/en/main/route/action) est une convention de Remix. Ajoutons cette méthode pour autoriser les requêtes `POST` dans notre route. ```tsx app/routes/_index.tsx focus=1:4 import type { ActionFunctionArgs } from '@remix-run/node'; export const action = async ({ request }: ActionFunctionArgs) => { return null; }; export default function Index() { return (
); } ``` L'erreur est réparée. On peut passer à la suite. ## Validation d'un formulaire côté serveur Soumettre notre formulaire (en cliquant sur le `button`) effectue un `POST` sur notre route, et va déclencher la méthode `action`. Cette méthode ne fait rien à part renvoyer `null`. Nous allons ajouter un peu de logique pour : - extraire les données du formulaire - les valider manuellement - envoyer un retour à l'utilisateur en cas d'erreur ### Récupération des données de formulaire côté serveur Avant de valider les données côté serveur, nous devons les récupérer. Voici la solution. ```tsx app/routes/_index.tsx focus=1:6 import type { ActionFunctionArgs } from '@remix-run/node'; export const action = async ({ request }: ActionFunctionArgs) => { const formData = await request.formData(); const name = formData.get('name'); return null; }; export default function Index() { return (
); } ``` Explications : Au moment du `POST`, notre formulaire va récupérer chaque valeur de ses `input` __possédant la propriété `name`__. Je reformule. Si votre `input` n'a pas de propriété `name`, sa valeur ne pourra être récupérée côté serveur. C'est un pré-requis. Cette propriété permet d'identifier l'`input` côté serveur. Ensuite, une requête est effectuée à notre action avec les données de notre formulaire. C'est cette requête que nous récupérons comme argument dans notre *action*. La `request` possède plusieurs informations, notamment la méthode `formData` qui va nous permettre de récupérer les données du formulaire. C'est une promesse, nous devons utiliser `await`. Cette méthode nous renvoie un objet [FormData](https://developer.mozilla.org/en-US/docs/Web/API/FormData) possédant plusieurs méthodes. > Le `FormData` n'est pas exclusif à l'environnement serveur. Nous pouvons utiliser cette interface côté client, par exemple en utilisant le props `onSubmit` dans notre `form`. Chaque valeur peut être récupérée en utilisant la méthode `.get($key)` de notre `FormData`. **$key** représente la valeur de la propriété `name` de l'input. Dans notre cas, nous l'avons appelé `name`. Je vous présenterai également un moyen de transformer le `formData` en objet clé-valeur (pour ne plus avoir à utiliser `formData.get()`. ### Valider les données de formulaire côté serveur #### Pourquoi valider nos données de formulaire ? Pourquoi valider nos données ? Pour nous assurer que les données reçues sont conformes à ce que nous attendons. Nous allons par exemple valider qu'un numéro de téléphone contient 10 caractères. Sinon, pas la peine de sauvegarder la donnée : On imagine que le numéro est sûrement erroné. J'ai déjà eu à valider des adresses emails, des numéro SIRET et des numéros de TVA. Ajouter une étape de validation empêche les farceurs de spam notre base de données avec des valeurs inutilisables. Nous pouvons valider notre donnée de plusieurs manières. - En validant "manuellement" (avec des `if`) - En utilisant la librairie [tiny-invariant](https://www.npmjs.com/package/tiny-invariant) - En utilisant [Zod](https://zod.dev) > Je n'utilise personnellement jamais la validation manuelle #### Validation manuelle de nos données de formulaire À titre d'exemple, nous allons interdire l'utilisation des prénoms à moins de 3 caractères. Côté serveur, cela implique deux vérifications : - Vérifier que la valeur est bien un `string` (et pas un fichier) - Vérifier que le nom fait moins de 3 caractères Nous devons aussi renvoyer au client un message d'erreur ou de succès. Côté client, nous faisons quelques modifications : - Nous récupérons le message d'erreur ou de succès avec le hook [useActionData](https://remix.run/docs/en/main/hooks/use-action-data) - Nous l'affichons conditionnellement à l'utilisateur. ```tsx app/routes/_index.tsx focus=2,7:18,22,26 import type { ActionFunctionArgs } from '@remix-run/node'; import { useActionData } from '@remix-run/react'; export const action = async ({ request }: ActionFunctionArgs) => { const formData = await request.formData(); const name = formData.get('name'); if (typeof name !== 'string') { return { message: 'Le nom est requis', }; } if (name.length < 3) { return { message: 'Le nom doit contenir au moins 3 caractères', }; } return { message: 'Inscription réussie' }; }; export default function Index() { const actionData = useActionData(); return (
{actionData?.message ?

{actionData.message}

: null}
); } ``` ![Soumission d'un formulaire avec retour utilisateur sous forme de message](https://algomax-public.s3.eu-west-3.amazonaws.com/successful_feedback_4f841a2ca1.gif) Pour un cas d'utilisation très simple comme celui-ci, on peut s'arrêter là. Pas besoin d'installer deux librairies supplémentaires. Cependant, cet exemple ne reflète pas les applications que je pousse en production. Il y a souvent plus de trois champs aux formulaires que je développe. De plus, j'utilise déjà la librairie **zod** pour valider les données côté serveur (récupérées depuis une API [NestJS](https://algomax.fr/blog?categories=nestjs)) #### Validation de nos données de formulaire avec Zod Pour pouvoir utiliser [Zod](https://zod.dev), (c'est une librairie Javascript de validation de données), nous avons besoin de l'installer dans notre dossier projet. ```bash Terminal npm install zod ``` Ensuite, nous définissons un schéma représentant notre modèle de données. Reprenons l'exemple de notre nom à 3 caractères qui est de type `string`. Cela implique une refactorisation du code. Nous devons définir le schéma zod en ajoutant les instructions `.string()` et `.min(3)` (les messages d'erreurs sont facultatifs). ```ts const nameSchema = z.string({ required_error: 'Le nom est requis' }).min(3, { message: 'Le nom doit contenir au moins 3 caractères', }); ``` Ensuite, nous allons utiliser la méthode `.parse($data)` pour déclencher la validation de notre donnée `$data` (ici, ce sera notre `name`). ```ts const parsedName = nameSchema.parse(name); ``` Voici l'implémentation complète. ```tsx app/routes/_index.tsx focus=3,4:7,11:12 import type { ActionFunctionArgs } from '@remix-run/node'; import { useActionData } from '@remix-run/react'; import { z } from 'zod'; const nameSchema = z.string({ required_error: 'Le nom est requis' }).min(3, { message: 'Le nom doit contenir au moins 3 caractères', }); export const action = async ({ request }: ActionFunctionArgs) => { const formData = await request.formData(); const name = formData.get('name'); const parsedName = nameSchema.parse(name); return { message: 'Inscription réussie' }; }; export default function Index() { const actionData = useActionData(); return (
{actionData?.message ?

{actionData.message}

: null}
); } ``` Cette implémentation possède un **avantage** et un **inconvénient**. - L'avantage c'est la validation Zod qui permet de réutiliser cette logique (en exportant le schéma). C'est simple à maintenir et c'est lisible. - Le désavantage, c'est qu'en cas d'erreur (si le schéma n'est pas respecté), le message d'erreur de Zod ne sera pas affiché côté client. ![La validation Zod échoue, et l'erreur n'est pas attrapée.](https://algomax-public.s3.eu-west-3.amazonaws.com/failed_error_handling_97c8579ae5.gif) ```js ZodError: [ { "code": "too_small", "minimum": 3, "type": "string", "inclusive": true, "exact": false, "message": "Le nom doit contenir au moins 3 caractères", "path": [] } ] at Object.get error [as error] (file:///Users/dev/dev/remix-forms/node_modules/zod/lib/index.mjs:538:31) at ZodString.parse (file:///Users/dev/dev/remix-forms/node_modules/zod/lib/index.mjs:638:22) at action2 (file:///Users/dev/dev/remix-forms/app/routes/_index.tsx:11:32) ``` Nous avons deux solutions, chacune avec des avantages et des inconvénients. ##### Implémenter nous-même la gestion des erreurs Zod en utilisant 'safeParse' Cette solution possède un avantage : ne pas installer une librairie supplémentaire. L'inconvénient, c'est que plus le schéma devient complexe, plus la gestion des erreurs devient complexe ##### Utiliser la librairie Conform pour gérer les erreurs Cette [librairie](https://conform.guide/) a été conçue spécifiquement pour ce cas d'utilisation (validation de formulaires avec Remix et Zod) L'avantage principal, c'est que même avec un schéma complexe, le développeur n'aura pas plus de mal à implémenter le formulaire. Le désavantage, c'est qu'il faut installer une nouvelle librairie. Ça peut être un problème si vous ne voulez pas davantage ralentir votre webapp avec du JS. Cet article est biaisé, car il parle de l'intégration de Conform dans votre application Remix. #### Validation des données de formulaire avec Conform Nous avons besoin d'installer deux librairies pour utiliser Conform. - `@conform-to/react` pour utiliser son puissant hook `useForm`, valider les données côté client et afficher les erreurs - `@conform-to/zod` pour valider les données côté serveur et côté client avec Zod. Sans déclencher d'erreur en cas de non-validation. ```bash Terminal npm install @conform-to/react @conform-to/zod ``` Nous allons implémenter Conform en trois étapes. Modifier le schéma Zod (et l'adapter à Conform), ajouter la logique côté client, puis ajouter la logique côté serveur. ##### Adapter le schéma Zod à Conform ```ts focus=4:7 const nameSchema = z.string({ required_error: 'Le nom est requis' }).min(3, { message: 'Le nom doit contenir au moins 3 caractères', }); const Schema = z.object({ name: nameSchema, }); ``` Bien que ce formulaire ne possède qu'une propriété pour l'instant, Conform s'attend à recevoir un `FormData` en paramètres. Il le transforme ensuite en objet. Nous avons déclaré un nouveau `Schema` qui est un `z.object`, contenant une propriété `name` (qui utilise le schéma que nous avons défini toute à l'heure). ##### Ajouter 'useForm' côté client Conform utilise le schéma Zod pour déterminer les champs de notre formulaire. Notre `Schema` possède un champ (`name`). Nous utilisons le hook `useForm` pour récupérer les `props` de notre formulaire et de chacun de nos `input` (les `fields`). ```tsx app/routes/_index.tsx focus=1:2,14:22,24[9:31],25[11:59],26 import { getFormProps, getInputProps, useForm } from '@conform-to/react'; import { getZodConstraint, parseWithZod } from '@conform-to/zod'; import { z } from 'zod'; const nameSchema = z.string({ required_error: 'Le nom est requis' }).min(3, { message: 'Le nom doit contenir au moins 3 caractères', }); const Schema = z.object({ name: nameSchema, }); export default function Index() { const [form, fields] = useForm({ constraint: getZodConstraint(Schema), onValidate({ formData }) { return parseWithZod(formData, { schema: Schema, }); }, lastResult: undefined, }); return (
{fields.name.errors}
); } ``` On peut constater qu'on ne définit aucun `props` sur nos `input`. C'est Conform qui gère leur valeur, leur ID, le focus en cas d'erreur et plein d'autres fonctionnalités lié au [progressive enhancement](https://remix.run/docs/en/main/discussion/progressive-enhancement) pour offrir à nos utilisateurs une expérience optimale. Constatez aussi la méthode `parseWithZod`, utilisée pour valider les données du `formData` côté client, dans la méthode `onValidate`. C'est exactement ce que nous avons fait tout à l'heure côté serveur ! Le `FormData` vient du client, et n'est envoyé au serveur qu'après la soumission (et la première validation par Conform et Zod) ##### Validation des données côté serveur avec Conform et 'parseWithZod' Il nous manque la validation la plus importante. Celle qui est effectuée côté serveur. C'est dans notre action qu'on va vérifier les informations fournies par l'utilisateur. (Est-ce que l'utilisateur existe déjà ? A-t-il validé son mot de passe ? Ces exemples sont utilisés dans toutes les applications, même si notre implémentation ne le reflète pas) ```ts import { ActionFunctionArgs, json } from '@remix-run/node'; import { z } from 'zod'; const nameSchema = z.string({ required_error: 'Le nom est requis' }).min(3, { message: 'Le nom doit contenir au moins 3 caractères', }); const Schema = z.object({ name: nameSchema, }); export const action = async ({ request }: ActionFunctionArgs) => { const formData = await request.formData(); const submission = await parseWithZod(formData, { schema: Schema, }); if (submission.status !== 'success') { return json({ result: submission.reply() }); } return json({ result: submission.reply({ resetForm: true, }), }); }; ``` Nous devons toujours récupérer les valeurs du formulaire avec `await request.formData()`, sauf que cette fois on laisse Conform se charger de tout, grâce à la méthode `parseWithZod`. Cette méthode prend le `formData` et notre schéma Zod en deuxième argument. Il nous renvoie ensuite un objet `submission`, qui possède l'un des deux status : `error` et `success`. - Si le statut `error` est renvoyé, alors nous renvoyons une réponse Conform au client. Nous devons ensuite la passer comme argument dans le hook `useForm` (clé `lastResult`) pour qu'il puisse faire le lien entre la soumission qui a échouée côté serveur, et les inputs côté client. - Si le statut `success` est renvoyé, cela signifie que les données sont conformes au schéma. Il n'y a rien de plus à faire. On a implémenté la validation côté serveur. Voici le composant intégral (avec le `lastResult`) ```tsx app/routes/_index.tsx import { getFormProps, getInputProps, useForm } from '@conform-to/react'; import { getZodConstraint, parseWithZod } from '@conform-to/zod'; import { ActionFunctionArgs, json } from '@remix-run/node'; import { useActionData } from '@remix-run/react'; import { z } from 'zod'; const nameSchema = z.string({ required_error: 'Le nom est requis' }).min(3, { message: 'Le nom doit contenir au moins 3 caractères', }); const Schema = z.object({ name: nameSchema, }); export const action = async ({ request }: ActionFunctionArgs) => { const formData = await request.formData(); const submission = await parseWithZod(formData, { schema: Schema, }); if (submission.status !== 'success') { return json({ result: submission.reply() }); } return json({ result: submission.reply({ resetForm: true, }), }); }; export default function Index() { const actionData = useActionData(); const [form, fields] = useForm({ constraint: getZodConstraint(Schema), onValidate({ formData }) { return parseWithZod(formData, { schema: Schema, }); }, lastResult: actionData?.result, }); return (
{fields.name.errors}
); } ``` ### Conclusion En explorant l'implémentation d'un formulaire étape par étape avec [Remix](https://remix.run), nous avons découvert l'importance cruciale de l'expérience utilisateur (*UX*) dans la gestion des erreurs. Commencer par les fondamentaux nous a permis de comprendre comment récupérer et valider les données de formulaire côté serveur. L'utilisation de [Zod](https://zod.dev) nous a permis de consolider la validation des données, en ajoutant des messages d'erreurs clairs, tout en restant plus simple à maintenir qu'une gestion d'erreur "manuelle". Utiliser [Conform](https://conform.guide) nous a permi d'optimiser l'expérience utilisateur grâce à une validation efficace et des retours visuels, pour prévenir les utilisateurs de leurs erreurs éventuelles avec des messages d'erreurs de qualité. Je vous encourage à tester Remix avec ces outils ! Depuis que je les ai découvert, je ne m'en sépare plus. Votre feedback est précieux — n'hésitez pas à partager vos expériences, questions ou suggestions sur [Twitter](https://twitter.com/varkoffs) ou sur [LinkedIn](https://www.linkedin.com/in/virgile-rietsch/) si ça vous a été utile. Ensemble, améliorons l'UX de nos formulaires et offrons une expérience agréable à nos utilisateurs. --- ## 6 Routes à connaître si tu utilises Remix (guide complet) URL: https://algomax.fr/blog/les-6-routes-a-connaitre-avec-le-framework-remix-framework-react Publié le : 2024-02-09 Description : Remix est un framework de React qui permet de développer des applications web full-stack. Son routing puissant permet de créer un fichier dans le dossier routes pour créer une route API ou une vue. Envisages-tu de tester ou même d'utiliser le framework [Remix](https://remix.run) pour ton prochain projet ? Pour cela, il va falloir te familiariser avec son puissant *routing*. Cet article te liste les [**6** types de routes](https://www.youtube.com/watch?v=TOMMXhgUQfI) que tu vas utiliser au quotidien avec Remix. Si tu préfères lire la doc, Remix [explique tout en détail](https://remix.run/docs/en/main/file-conventions/routes) sur le site. ## Le routing, c'est quoi ? Commençons par définir ce qu'est le **routing** > C'est le chemin (sous forme d'URL) qui permet d'accéder à ton site internet Exemples : - [leboncoin.fr](https://leboncoin.fr) te permet d'accéder à la page d'accueil du bon coin, sa route "index". - [leboncoin.fr/annonces/offres](https://leboncoin.fr/annonces/offres) te permet d'accéder à une deuxième page du bon coin. La page est différente de la première, le chemin d'accès dans l'URL est différent. C'est une deuxième route. Tous les sites possèdent minimum une route (qu'on va appeler route *index*, ou route *par défaut*). Ce concept n'est pas récent. À mes débuts dans le développement, j'intégrais mes premières pages en HTML et PHP. La convention était de nommer nos fichiers **index.html** et **index.php**. Ces fichiers étaient ensuite accessibles au nom de domaine local. Par exemple, `localhost:8000`. Sans le savoir, j'avais déjà créé ma première *route* index. Avec l'arrivée de **React** et de ses framework, le routing se fait généralement sans configuration de notre part. (sauf si tu utilises React-Router, mais si c'est le cas, tu es au bon endroit !) ## Explication vidéo Nous avons fait un guide vidéo pour t'expliquer le routing de Remix avec plus d'exemples. ## Créer sa première route (type 1) Lorsques tu génères un nouveau projet Remix avec l'un de ses nombreux template, une route par défaut aura déjà été créée. Elle se situe dans ton dossier `app/routes` et se nomme **__index.tsx**. ```tsx app/routes/_index.tsx export default function Index() { return (

Hello world !

); } ``` Voici les **2 règles** à respecter pour créer une route avec la configuration par défaut de Remix : - Créer un fichier au format **.jsx** ou **.tsx** dans le dossier `app/routes`. - Le nommer (son nom va définir le chemin pour y accéder dans l'URL. Dans l'exemple ci-dessous, nous avons ajouté un composant React à l'intérieur de notre fichier. Cette vue sera accessible à la page d'accueil de notre site (par défaut `localhost:3000`) > Mais il n'est pas obligatoire d'exporter des composants React depuis nos routes. Cela dépend de ton besoin. Si tu veux juste créer un endpoint API (une route qui renvoie du JSON, par exemple), tu n'as pas besoin de déclarer un composant React. ```tsx app/routes/users.tsx export const loader = () => { return { name: 'Virgile' } } ``` Voici un exemple d'une route Remix, accessible à l'URL `localhost:3000/api`. Elle renvoie un objet au format JSON. ```json { name: "Virgile" } ``` ## Création d'une route dynamique (type 2) Pour créer une route dynamique, nous devons utiliser un nommage de fichier précis. Il nous suffit d'ajouter le préfixe **$** à notre nom de fichier. Par exemple, si je souhaite afficher le détail de l'utilisateur *Virgile** à l'adresse `http://localhost:3000/users/virgile`, je vais implémenter cette logique en deux étapes : - Nommer un fichier dans le dossier `app/routes`, nommé `users.$username.tsx` - Exporter par défaut un composant React pour afficher une vue, avec les informations de cet utilisateur Regardons avec un exemple. ```tsx app/routes/users.$username.tsx import { useParams } from '@remix-run/react'; export default function Username() { const username = useParams().username; return (

Salut {username} !

); } ``` Ici, nous donnons une instruction à Remix. Nous lui demandons de créer une route au chemin `users/virgile`. Le point (`.`) dans le nommage du fichier nous permet d'ajouter un *slash* dans l'URL. Ensuite, le *$* nous permet de nommer la clé du paramètre dans l'URL. Nous récupérons ensuite ce paramètre dynamique, nommé *username* dans notre composant React, côté client à l'aide du hook **useParams()** que nous importons depuis Remix. Ce fichier nous permet donc de créer une route qui va afficher une vue côté client, avec une valeur dynamique en fonction de la valeur que nous entrons dans l'URL. ![salut virgile](https://algomax-public.s3.eu-west-3.amazonaws.com/image_f689049259.png) La valeur de notre variable **username** est déterminée par le paramètre d'URL (soit *virgile*, dans cet exemple) ## Création d'une route imbriquée (type 3) La route *imbriquée* est similaire à la route dynamique. Nous nommons le fichier de la même manière qu'une route dynamique. La seule différence, c'est le contenu de la route **parent** (dans notre exemple, la route **users.tsx**) est visible sur la page. C'est très pratique pour afficher par exemple système d'onglets dans notre application. ![Exemple de page avec des onglets](https://algomax-public.s3.eu-west-3.amazonaws.com/tabs_502db141b3.jpeg) Nous pourrions très bien reproduire cet exemple sous forme de route imbriquée. La route parent afficherait les onglets, et le contenu de l'onglet (Subtopic 1) serait affiché dans la route enfant. Faisons d'abord une petite refactorisation. ```tsx app/routes/users.tsx import { Link } from '@remix-run/react'; export default function Users() { return (

Liste des utilisateurs

    {['Virgile', 'Cédric'].map((username) => ( {username} ))}
); } ``` Nous affichons maintenant une liste de deux utilisateurs sur la route `localhost:3000/users`, *Virgile* et *Cédric*. Nous avons également des liens pour accéder à leur information. Spoiler, mais ça ne va pas avoir l'effet désiré. On n'est cependant pas loin du but. En théorie, il suffirait de changer l'URL à `localhost:3000/cedric` pour afficher la vue pour cet utilisateur (c'est la route dynamique que nous avons créée plus haut). Malheureusement, après avoir cliqué sur le lien, on se rend compte que la page n'a pas changé 🤔 ?? ![image.png](https://algomax-public.s3.eu-west-3.amazonaws.com/image_ec2c10077b.png) Et bien, si. Nous avons réussi à donne l'instruction à Remix de créer une route **imbriquée**. Sauf qu'on a oublié un composant magique nous permettant de placer la position de l'enfant dans le DOM. En fait, la page ci-dessus affiche toujours le contenu du parent (les liens de nos utilisateurs), mais elle n'affiche pas la route enfant car on ne lui a pas donné l'instruction. (il n'y a donc aucun bug, rassurez-vous) > Que dois-je faire pour faire apparaître ma route enfant ? Le composant `` est la pièce manquante pour bénéficier des routes imbriquées avec Remix. En effet, si nous accédons à la route parent (`localhost:3000/users`), Remix affiche la route `users.tsx`. Mais si on accède à la route `localhost:3000/users/cedric`, Remix va regarder le nom de notre fichier `users.$userId.tsx`. Et il va vérifier trois éléments : - Est-ce qu'il y a un paramètre d'URL dynamique (symbolisé par le `$`) - Est-ce qu'il existe une route parent (dans notre cas, `users.tsx` - Est-ce que la route parent possède un composant `` Rajoutons maintenant le [composant Outlet](https://remix.run/docs/en/main/components/outlet) et regardons ce qui se passe. ```tsx tsx app/routes/users.tsx focus=14 import { Link, Outlet } from '@remix-run/react'; export default function Users() { return (

Liste des utilisateurs

    {['Virgile', 'Cédric'].map((username) => ( {username} ))}
); } ``` ![La route imbriquée s'affiche correctement](https://algomax-public.s3.eu-west-3.amazonaws.com/image_aff718efe0.png) En résumé, ajouter une route imbriquée est relativement *simple*. Il suffit de rajouter le composant `` dans la route parent. Et Remix se charge du reste. ## Création d'une route layout (type 4) Reprenons l'exemple de nos onglets pour mieux comprendre l'intérêt d'une route **layout**. On va commencer par la définir, en la comparant à une route imbriquée. > Une route layout, c'est une route imbriquée, mais le chemin n'est pas visible dans l'URL. Par exemple, si vous souhaitez afficher un composant spécial sur certaines pages, mais pas sur d'autres (ou bien un modal qui apparaît après 5 secondes, c'est vous qui voyez), c'est totalement possible grâce aux routes *Layout*. Pour créer une route layout, il suffit de rajouter le préfixe `_` (underscore) à la route parent. Son nom va disparaître de l'URL. Essayons tout de suite avec notre route `users.tsx`. (Le contenu du fichier ne change pas, seulement son nom) ```tsx app/routes/_users.tsx import { Link, Outlet } from '@remix-run/react'; export default function Users() { return (

Liste des utilisateurs

    {['Virgile', 'Cédric'].map((username) => ( {username} ))}
); } ``` Il faut aussi modifier le fichier `users.$username.tsx` pour qu'il soit considéré comme "faisant partie du layout". ```tsx app/routes/_users.$username.tsx import { useParams } from '@remix-run/react'; export default function Username() { const username = useParams().username; return

Salut {username} !

; } ``` Maintenant, notre liste d'utilisateurs ne sera plus visible au chemin `localhost:3000/users`. Elle ne sera plus visible du coup, pas même à l'URL `localhost:3000` (c'est la route _index.tsx qui s'affiche à la place). Le détail de notre utilisateur sera cependant accessible à la route enfant `localhost:3000/cedric`, ainsi que le contneu de notre layout (la liste de nos deux utilisateurs) ## Créer une route ressource (JSON, PDF, CSV ...) (type 5) Vous vous souvenez de la route basique qu'on a créé en tout début de l'article ? Une [route ressource](https://remix.run/docs/en/main/guides/resource-routes#creating-resource-routes) est exactement pareil. Il suffit de créer un fichier dans le dossier `app/routes`, mais au lieu d'exporter un composant React par défaut (notre vue), nous exportons une méthode nommée `loader` (pas besoin de l'exporter par défaut) Essayons avec un exemple. Je souhaite afficher une image aléatoire à l'URL `localhost:3000/image`. Je vais donc récupérer mon image depuis le site [picsum.photos](https://picsum.photos) Il me suffit donc de créer un fichier nommé `image.tsx` (dans le dossier `app/routes`), puis d'exporter une *fonction* nommée `loader` Essayons voir. ```tsx app/routes/image.tsx export const loader = async () => { const response = await fetch('https://picsum.photos/200/300'); const blob = await response.blob(); return new Response(blob, { headers: { 'Content-Type': 'image/jpeg', }, }); }; ``` ![resource-route.gif](https://algomax-public.s3.eu-west-3.amazonaws.com/resource_route_203bd1f2a2.gif) Je n'ai jamais créé une route API aussi facilement. ## Créer une route 404 (type 6) Nous allons maintenant créer notre dernier type de route, la fameuse page *Erreur 404*. Si vous lisez l'article depuis le début, vous comprendrez vite comment l'implémenter. Indice : C'est comme une route dynamique, mais le paramètre d'URL n'est pas nommé. > Il faut nommer le fichier `$.tsx` Pour afficher une vue à n'importe quelle page que Remix n'identifie pas comme étant un chemin valide, il faut également exporter un composant React par défaut. Passons à l'implémentation. ```tsx app/routes/$.tsx import { useLocation } from '@remix-run/react'; export default function FourOhFour() { const location = useLocation(); return (

Oops, on a pas trouvé la route{' '} {location.pathname} !

); } ``` Essayons un chemin pour voir. Au hasard, `localhost:3000/youtube/abonnez-vous`. ![Route 404](https://algomax-public.s3.eu-west-3.amazonaws.com/404_route_951a872cfc.gif) Petites précisions : - Remix priorise les routes nommées. Si vous tapez `localhost:3000/image` dans l'URL, Remix va d'abord regarder les routes nommées, pas dynamiques (un match exact) avec le nom. C'est le cas pour nous avec le fichier `image.tsx` - Ensuite s'il ne trouve pas, il va chercher une route dynamique (avec le préfixe `$`). C'est le cas avec le fichier `_users.$username.tsx`, qui va matcher n'importe qu'elle URL à la place de l'étoile `localhost:3000/*`, à l'exception des routes nommées (exact match), et des routes imbriquées (plusieurs `/` (slash) dans l'URL) - Nous essayons d'accéder à la route `localhost:3000/youtube/abonnez-vous`, qui n'est donc pas un paramètre d'URL car il y a un `/`. On renvoie donc sur une page 404. ## Conclusion Nous venons de voir tous les types de page nécessaires pour vous permettre de créer des belles [applications web sur mesure](/creation-applications-web-sur-mesure). Si vous voulez aller plus loin et configurer vous-même vos règles de routing (ou changer les préfixes, tels que `.`, `$` et `_`, c'est possible. La librairie [remix-flat-routes](https://github.com/kiliman/remix-flat-routes) vous le permet, et je l'utilise dans tous mes projets ! --- ## CMS headless : faut-il utiliser Strapi pour votre site ou application ? URL: https://algomax.fr/blog/decouvrez-strapi-la-solution-cms-headless-pour-des-experiences-web-modernes Publié le : 2024-02-07 Description : Strapi est un CMS headless open source qui sépare le contenu de l'affichage. Découvrez s'il convient à votre projet web ou application, et dans quels cas l'utiliser. # CMS headless : faut-il utiliser Strapi pour votre site ou application ? Vous voulez pouvoir modifier le contenu de votre site web sans appeler un développeur à chaque fois. Ajouter un article de blog, changer une photo, mettre à jour vos tarifs. C'est normal. C'est exactement à ça que sert un CMS (un système de gestion de contenu). Mais tous les CMS ne se valent pas, et le choix du bon outil peut avoir un impact direct sur la qualité de votre produit et votre autonomie au quotidien. Aujourd'hui, on parle de Strapi, un CMS dit "headless", et on va voir ensemble dans quels cas il est pertinent pour votre projet. ## D'abord, c'est quoi un CMS ? CMS signifie "Content Management System", ou système de gestion de contenu en français. C'est un outil qui vous permet de créer, modifier et organiser le contenu de votre site web ou de votre application depuis une interface simple, sans toucher au code. Le CMS le plus connu, c'est WordPress. Si vous avez déjà géré un blog ou un site vitrine, vous l'avez probablement croisé. Vous vous connectez à un panneau d'administration, vous écrivez votre texte, vous ajoutez des images, vous cliquez sur "Publier". Le contenu apparaît sur votre site. ## Et "headless", ça veut dire quoi ? C'est là que ça devient intéressant. Un CMS classique comme WordPress gère deux choses en même temps : le contenu (vos textes, images, données) et l'affichage (la façon dont ce contenu apparaît sur votre site). Les deux sont liés. Votre contenu est prisonnier de votre site WordPress. Un CMS headless sépare ces deux parties. Le mot "headless" signifie littéralement "sans tête". La "tête", c'est la partie visible, l'affichage. Un CMS headless gère uniquement le contenu. L'affichage est géré par un autre outil, indépendamment. Pourquoi c'est utile ? Parce que votre contenu devient réutilisable. Le même texte, les mêmes images, les mêmes données peuvent alimenter votre site web, votre application mobile, votre newsletter, vos écrans en magasin. Vous gérez tout depuis un seul endroit, et chaque canal va chercher le contenu dont il a besoin. ## Strapi, c'est quoi ? Strapi est un CMS headless open source. Décomposons ces termes. **CMS headless** : on vient de l'expliquer. Il gère le contenu, pas l'affichage. **Open source** : le code de Strapi est public et gratuit. Vous pouvez l'utiliser sans payer de licence. Vous pouvez l'héberger sur vos propres serveurs. Vos données vous appartiennent, elles ne sont pas stockées chez un tiers. Strapi propose une interface d'administration claire et intuitive. Vos équipes se connectent, créent du contenu, le publient. Les développeurs, de leur côté, configurent la structure des données et connectent Strapi au site web ou à l'application. ## Dans quels cas utiliser Strapi ? Strapi n'est pas la bonne solution pour tout le monde. Voici les situations où il est particulièrement adapté. ### Vous avez un blog ou un magazine en ligne Si vous publiez régulièrement des articles, des actualités ou des guides, Strapi vous permet de structurer votre contenu proprement. Vous définissez les champs dont vous avez besoin (titre, résumé, image à la une, catégorie, auteur) et vos rédacteurs remplissent un formulaire simple. Le contenu est ensuite affiché sur votre site avec le design de votre choix. ### Vous gérez un catalogue de produits ou de services Un site e-commerce ou une marketplace a besoin d'une base de données de produits. Strapi permet de créer des fiches produits avec tous les champs nécessaires (nom, description, prix, photos, caractéristiques techniques). Votre équipe commerciale peut mettre à jour les fiches sans dépendre de l'équipe technique. ### Vous diffusez du contenu sur plusieurs canaux C'est le cas d'usage principal d'un CMS headless. Si votre contenu doit apparaître sur un site web, une application mobile, et peut-être une borne interactive ou un écran d'affichage, Strapi centralise tout. Vous écrivez une seule fois, et chaque support récupère ce dont il a besoin. ### Vous construisez un outil interne Beaucoup d'entreprises utilisent Strapi comme back-office pour des outils internes. Gestion de projets, base de connaissances, annuaire d'employés. L'interface d'administration est suffisamment flexible pour s'adapter à des usages variés. ## Dans quels cas éviter Strapi ? Soyons honnêtes. Strapi n'est pas toujours le bon choix. **Vous avez besoin d'un simple site vitrine de 5 pages.** Si votre site ne change quasiment jamais, un CMS est peut-être superflu. **Vous n'avez pas de développeur dans l'équipe (et pas de prestataire technique).** Strapi nécessite une installation et une configuration initiale par un développeur. L'interface d'administration est simple à utiliser ensuite, mais la mise en place demande des compétences techniques. **Votre budget est très limité et votre projet très petit.** L'architecture headless ajoute une couche de complexité qui n'est pas toujours justifiée. ## Strapi vs WordPress vs Contentful | Critère | WordPress | Strapi | Contentful | |---|---|---|---| | Facilité d'installation | Très simple | Nécessite un dev | Aucune installation | | Multi-canal | Limité | Oui | Oui | | Propriété des données | Oui (auto-hébergé) | Oui (auto-hébergé) | Non (cloud tiers) | | Coût à long terme | Faible | Faible à moyen | Élevé | | Personnalisation | Extensions/thèmes | Très flexible | Limité au plan | | Idéal pour | Sites classiques, blogs | Apps, multi-canal, SaaS | Équipes sans dev, prototypage | **WordPress** reste un très bon choix pour un blog simple ou un site vitrine classique. Mais il mélange contenu et affichage, ce qui le rend moins flexible pour les projets multi-canaux. **Contentful** est un CMS headless commercial, hébergé dans le cloud. Pratique, mais vos données sont chez Contentful. Et les tarifs montent vite dès que votre volume de contenu augmente. **Strapi** se positionne entre les deux. Flexible et multi-canal comme Contentful, mais open source et auto-hébergeable comme WordPress. La contrepartie : il faut gérer l'hébergement et la maintenance. ## Comment nous utilisons Strapi chez Algomax Chez [Algomax](/), nous intégrons Strapi dans les projets de nos clients quand c'est pertinent. Pas systématiquement, parce que chaque projet a ses propres besoins. Quand un client nous demande une [application web](/services/application-web) ou une [plateforme SaaS](/services/application-saas) qui nécessite une gestion de contenu, Strapi fait souvent partie de notre recommandation. Nous l'installons, configurons les types de contenu en fonction des besoins métier, et connectons Strapi au front-end. L'avantage pour nos clients : une fois le projet livré, ils sont autonomes. Ils peuvent ajouter des articles, modifier des fiches produits, gérer leurs contenus sans nous appeler. Et si un jour ils veulent lancer une [application mobile](/services/application-mobile) en complément de leur site, le contenu est déjà prêt. Il suffit de le connecter. ## Ce qu'il faut retenir Strapi est un outil puissant pour les projets qui ont besoin d'une gestion de contenu flexible et indépendante de l'affichage. Ce n'est pas un remplaçant de WordPress pour tout le monde. C'est une solution adaptée à des projets plus ambitieux ou plus techniques. Si vous ne savez pas quel CMS choisir pour votre projet, c'est normal. Le bon choix dépend de votre contexte, de vos objectifs et de votre budget. [Prenez contact avec l'équipe Algomax](/contact) pour en discuter. Nous vous aiderons à choisir l'architecture la plus adaptée, sans vous vendre une solution dont vous n'avez pas besoin. --- ## Figma : pourquoi cet outil de design change tout pour votre projet digital URL: https://algomax.fr/blog/les-avantages-incontournables-de-figma-pour-les-developpeurs Publié le : 2024-02-07 Description : Figma est devenu l'outil de référence pour le design d'applications et de sites web. Découvrez pourquoi il accélère vos projets et améliore la collaboration entre vos équipes. # Figma : pourquoi cet outil de design change tout pour votre projet digital Vous avez un projet d'application ou de site web en tête. Vous avez trouvé un prestataire, défini un budget, listé vos besoins. Et puis on vous dit : "On commence le développement lundi." Stop. Avant d'écrire la moindre ligne de code, il y a une étape que beaucoup de porteurs de projet négligent. Cette étape, c'est le design de l'interface. Et l'outil qui a transformé cette étape, c'est Figma. ## Figma, c'est quoi exactement ? Figma est un logiciel de design d'interfaces. Concrètement, il permet de dessiner les écrans de votre futur site web ou de votre application mobile, pixel par pixel, avant que quoi que ce soit ne soit codé. Pensez-y comme un plan d'architecte, mais pour le numérique. Vous ne construiriez pas une maison sans plan. Pourtant, beaucoup d'entreprises se lancent dans le développement d'un produit digital sans avoir vu à quoi il ressemblera. Figma fonctionne entièrement dans le navigateur. Pas besoin d'installer quoi que ce soit. Vous recevez un lien, vous cliquez, et vous voyez les maquettes de votre projet. Vous pouvez commenter, annoter, poser des questions, directement sur le design. Votre prestataire voit vos retours en temps réel. ## Pourquoi c'est important pour vous (même si vous ne designez rien) Si vous êtes dirigeant, fondateur ou responsable d'un projet digital, Figma vous concerne directement. Voici pourquoi. ### Vous voyez avant de payer Le plus gros risque dans un projet digital, c'est de payer pour quelque chose qui ne correspond pas à ce que vous aviez en tête. Avec Figma, vous voyez chaque écran, chaque bouton, chaque interaction avant le début du développement. Si quelque chose ne va pas, on modifie une maquette en quelques minutes. Modifier du code, c'est des jours de travail. La différence de coût est considérable. ### Vous comprenez ce que vous achetez Les cahiers des charges techniques sont souvent incompréhensibles pour un non-technicien. Un document de 40 pages décrivant des "endpoints API" et des "schémas de base de données" ne vous aide pas à prendre des décisions. Une maquette Figma, si. Vous voyez l'écran de connexion. Vous voyez le tableau de bord. Vous voyez le parcours d'un utilisateur de A à Z. C'est concret. ### Tout le monde travaille sur la même base Votre équipe marketing veut voir le rendu visuel. Votre associé veut valider les fonctionnalités. Votre futur investisseur veut comprendre le produit. Avec Figma, vous partagez un seul lien. Chacun peut consulter les maquettes, laisser des commentaires, et tout est centralisé au même endroit. Fini les allers-retours par email avec des captures d'écran floues. ## Comment Figma s'intègre dans un projet concret Un projet digital bien mené suit généralement ces étapes : **1. Les wireframes (maquettes fil de fer)** Ce sont des schémas simplifiés, en noir et blanc, qui définissent la structure de chaque page. Où se trouve le menu ? Où affiche-t-on les informations principales ? Quel est le parcours de l'utilisateur ? À ce stade, on ne parle pas de couleurs ni de logo. On organise l'information. **2. Les maquettes haute fidélité** Une fois la structure validée, on applique l'identité visuelle : couleurs, typographies, images, icônes. Le résultat ressemble exactement à ce que verra l'utilisateur final. Vous pouvez montrer ces maquettes à vos clients, vos partenaires, votre équipe. **3. Le prototype interactif** Figma permet de relier les écrans entre eux pour simuler la navigation. Vous cliquez sur un bouton, et vous arrivez sur l'écran suivant. On dirait une vraie application, sauf qu'il n'y a aucun code derrière. Ce prototype vous permet de tester l'expérience utilisateur avant d'investir dans le développement. **4. Le handoff (passage aux développeurs)** Figma génère automatiquement les spécifications techniques dont les développeurs ont besoin : dimensions, espacements, couleurs en code hexadécimal, tailles de police. Les développeurs n'ont pas besoin de deviner. Tout est documenté dans l'outil. ## Figma vs l'ancienne méthode Il n'y a pas si longtemps, le design de sites web se faisait avec Photoshop ou Illustrator. Le designer créait un fichier, l'exportait en image, l'envoyait par email. Le client ouvrait le fichier (quand il arrivait à l'ouvrir), envoyait ses retours dans un email séparé. Le designer faisait les modifications, renvoyait une nouvelle version. "Maquette_v3_final_FINAL2.psd", ça vous parle ? Les problèmes étaient nombreux. Les fichiers étaient lourds et difficiles à partager. Impossible de commenter directement sur le design. Aucune interactivité, juste des images fixes. Les développeurs devaient mesurer les dimensions à la main. Et chaque modification demandait un nouveau cycle d'envoi. Figma a éliminé tous ces problèmes. Le fichier est en ligne, toujours à jour. Les commentaires sont directement sur le design. Le prototype est cliquable. Les développeurs extraient les informations techniques eux-mêmes. Et plusieurs personnes peuvent travailler sur le même fichier en même temps. ## Pourquoi vous devriez exiger un prototype avant le développement Voici une situation que nous voyons régulièrement. Un client vient nous voir après avoir dépensé 15 000, 30 000, parfois 50 000 euros chez un autre prestataire. L'application est développée. Elle fonctionne techniquement. Mais l'interface est confuse, les utilisateurs ne comprennent pas comment naviguer, et le produit ne correspond pas à la vision initiale. Le problème ? Le développement a commencé sans phase de design. Ou avec quelques croquis sur un coin de table. Un prototype Figma coûte une fraction du budget de développement. Il permet de valider (ou d'invalider) des hypothèses avant d'engager les gros moyens. Vous pouvez le montrer à de futurs utilisateurs, recueillir leurs avis, ajuster le produit. Tout ça sans avoir écrit une seule ligne de code. Si votre prestataire ne vous propose pas de phase de prototypage, posez-vous des questions. Ce n'est pas un luxe. C'est une assurance contre les erreurs coûteuses. ## Comment nous utilisons Figma chez Algomax Chez [Algomax](/), chaque projet commence par une phase de design dans Figma. Que ce soit pour une [application web](/services/application-web), une [plateforme SaaS](/services/application-saas), ou une [application mobile](/services/application-mobile), nous suivons le même processus. Nous commençons par comprendre vos besoins lors d'un échange. Ensuite, nous créons les wireframes pour structurer l'information et les parcours utilisateurs. Une fois validés, nous passons aux maquettes haute fidélité avec votre charte graphique. Puis nous assemblons un prototype cliquable que vous pouvez tester vous-même, sur votre téléphone ou votre ordinateur. Ce n'est qu'après votre validation du prototype que nous passons au développement. Cette approche nous permet de livrer des produits qui correspondent réellement à ce que nos clients avaient en tête. Vous avez un projet digital en tête ? [Contactez l'équipe Algomax](/contact) pour en discuter. Nous commencerons par vous montrer à quoi il pourrait ressembler, avant de parler code. --- ## Ce hook de React sauvegarde un paramètre URL sans recharger la page ! URL: https://algomax.fr/blog/ce-hook-de-react-sauvegarde-un-parametre-url-sans-recharger-la-page Publié le : 2023-11-30 Description : J'ai récemment découvert ce hook puissant, qui permet de changer un paramètre d'URL sans recharger la page. Parfait pour créer une fonctionnalité de recherche J'ai découvert ce hook il y a quelques jours sur le [Discord](https://rmx.as/discord) de [Remix](https://remix.run). Encore mieux que le hook [useSearchParams()](https://remix.run/docs/en/main/hooks/use-search-params), qui permet de modifier les paramètres dans l'URL. Il effectue également un **rechargement** des données côté serveur (et donc, de la page). ## useUpdateQueryStringValueWithoutNavigation Je souhaitais éviter de recharger la page à chaque fois, et j'ai découvert [**useUpdateQueryStringWithoutNavigation**](https://github.com/kentcdodds/kentcdodds.com/blob/main/app/utils/misc.tsx#L299). Lien vers le hook : [https://github.com/kentcdodds/kentcdodds.com/blob/main/app/utils/misc.tsx#L299](https://github.com/kentcdodds/kentcdodds.com/blob/main/app/utils/misc.tsx#L299) ```tsx useUpdateQueryStringValueWithoutNavigation.tsx function useUpdateQueryStringValueWithoutNavigation( queryKey: string, queryValue: string, ) { React.useEffect(() => { const currentSearchParams = new URLSearchParams(window.location.search) const oldQuery = currentSearchParams.get(queryKey) ?? '' if (queryValue === oldQuery) return if (queryValue) { currentSearchParams.set(queryKey, queryValue) } else { currentSearchParams.delete(queryKey) } const newUrl = [window.location.pathname, currentSearchParams.toString()] .filter(Boolean) .join('?') // alright, let's talk about this... // Normally with remix, you'd update the params via useSearchParams from react-router-dom // and updating the search params will trigger the search to update for you. // However, it also triggers a navigation to the new url, which will trigger // the loader to run which we do not want because all our data is already // on the client and we're just doing client-side filtering of data we // already have. So we manually call `window.history.pushState` to avoid // the router from triggering the loader. window.history.replaceState(null, '', newUrl) }, [queryKey, queryValue]) } ``` --- ## Créer un serveur API avec NestJS: guide complet URL: https://algomax.fr/blog/creer-un-serveur-api-avec-nest-js-le-guide-ultime Publié le : 2023-09-16 Description : Architecture, endpoints, validation et bonnes pratiques pour construire une API NestJS stable et évolutive. > Mise à jour SEO (Mars 2026) > > Guide terrain pour poser une API NestJS claire: structure, validation des entrées et conventions utiles en équipe. Quand j'ai commencé à développer des serveurs API en NodeJS, j'avais **beaucoup de mal** à utiliser Express. J'étais débutant, et je ne connaissais pas encore tous les concepts de développeur : réutiliser du code, fonctions asynchrones et Typescript. Je voulais voir comment les pros faisaient. Je voulais lire du code propre et bien organisé. Je ne voulais surtout pas coder toutes mes routes dans le même fichier ! Puis j'ai découvert NestJS. Son **générateur de projet** m'a été d'une grande aide. Je pouvais, grâce à son outil [CLI](https://docs.nestjs.com/cli/overview) générer une base de code en **Typescript** avec **Express** déjà configuré. Il y avait des exemples de _routes_, un _contrôleur_, un _service_ et un _module_. En plus, la [documentation](https://docs.nestjs.com) était très concise. Ça m'a plu. ## Pourquoi utiliser NestJS comme serveur API ? J'avais un besoin spécifique : Créer une base de données pour sauvegarder des données. Récupérer ces données côté client et les afficher. Et pouvoir les modifier (toujours côté client). NestJS a répondu à ce besoin **rapidement**. Donc je l'ai choisi. Je recommande ce framework aux développeurs qui veulent créer un serveur API en **Javascript**. Mais je ne le recommande pas parce qu'il est mieux que les autres (il l'est 😉). Je le recommande, car il est dogmatique : il impose une structure de code. Il nous force à réfléchir à la manière dont on va organiser notre code. Pour un développeur débutant, c'est un **excellent** moyen d'apprendre à coder proprement. ## Pré-requis Assure-toi d'avoir [Node](https://nodejs.org/en/) et [NPM](https://www.npmjs.com) installés sur votre machine. Des connaissances en **Javascript** et **Git** sont recommandées. Nous allons aussi beaucoup utiliser **le terminal de commande**. ## Ce que tu vas apprendre et construire - Les bases de [NestJS](https://nestjs.com) (routes, contrôleurs, services, modules) - Utiliser l'ORM [Prisma](https://prisma.io) pour gérer la base de données - Créer quelques comptes utilisateurs (connexion et inscription par email / mot de passe) - Envoyer des alertes par email (nouveau compte, mot de passe oublié) avec [Courier](https://courier.com) - Ajouter l'authentification avec JWT pour les identifier - FRONTEND : Instantier un projet React avec [Remix](https://remix.run) - Créer un formulaire d'inscription et de connexion - Connecter le frontend et le backend - Créer un chat en temps réel avec [Socket.io](https://socket.io) (implémentation backend) - Implémenter le chat côté frontend - Héberger le code source sur [Github](https://github.com) (backend et frontend) - DÉPLOIEMENT : Commander un serveur d'hébergement (VPS) sur [Amazon Lightsail](https://aws.amazon.com/fr/lightsail) - Configurer le nom de domaine avec Amazon [Route 53](https://aws.amazon.com/fr/route53) - Configurer [Caddy](https://caddyserver.com) sur le serveur - Créer le fichier [Docker](https://www.docker.com) pour le serveur (et le frontend) - Configurer les [Github Actions](https://github.com/features/actions) pour héberger notre code source à chaque commit - Ajouter les variables d'environnement au repository Github - Tester l'application en production - FEATURE : Ajouter la logique d'upload des images - Héberger les images sur [AWS S3](https://aws.amazon.com/fr/s3) - FEATURE : Ajouter la logique de paiement avec [Stripe](https://stripe.com/docs?locale=fr-FR) - Paramétrer et écouter les websockets de Stripe pour recevoir les évènements de paiement ## Stack technique Voici la stack que j'utilise au quotidien : ### Côté serveur (backend) - Framework [NestJS](https://nestjs.com) - librairie [Fastify](https://fastify.dev) comme serveur HTTP. Pareil qu'Express, mais **2x plus rapide**. - [Prisma ORM](https://prisma.io) pour définir le modèle de nos données - base de donnée **MySQL** hébergée sur [Planetscale](https://planetscale.com) - [Socket.io](https://socket.io) pour envoyer les messages en temps réel (websockets) - [Stripe](https://stripe.com/docs?locale=fr-FR) pour envoyer de l'argent - Courier / Resend pour envoyer les emails (compte créé, mot de passe oublié, nouveau message reçu ...) - [AWS S3](https://aws.amazon.com/fr/s3) pour héberger les images - [Passport](https://docs.nestjs.com/recipes/passport) pour gérer l'authentification en créant un token sécurisé [JWT](https://jwt.io) - [Zod](https://zod.dev) pour valider les données - et bien d'autres ... ### Côté client (frontend) - [React 18](https://react.dev) pour créer une belle UI - Framework [Remix](http://remix.run) pour gérer nos routes et le rendu côté serveur (SSR) - [Tailwind CSS](https://tailwindcss.com) pour le design du chat - Également [Zod](https://zod.dev), [Stripe](https://stripe.com/docs?locale=fr-FR) et [Socket.io](https://socket.io) ### Déploiement - Amazon [Route 53](https://aws.amazon.com/fr/route53) pour le nom de domaine - Amazon [Lightsail](https://aws.amazon.com/fr/lightsail) pour le serveur d'hébergement (VPS) - Github [Actions](https://github.com/features/actions) pour déployer automatiquement notre code - [Docker](https://docker.com) pour exécuter notre code dans un environnement virtualisé - [Caddy](https://caddyserver.com) pour gérer les certificats SSL ## Formation vidéo Tu peux également suivre ce guide au format vidéo. ### Créer ton premier serveur API avec NestJS (Authentification par JWT) ### Développe ta MESSAGERIE en TEMPS RÉEL avec Socket.io ### Héberge tes IMAGES sur AWS S3 en Javascript ### Gère des PAIEMENTS en JAVASCRIPT avec STRIPE.JS ## Installation du projet Maintenant c'est à toi de jouer ! Pour **créer ta super API**, tu dois d'abord installer l'outil **CLI**. ```sh Terminal npm i -g @nestjs/cli ``` Tu vas maintenant créer le dossier du projet. Il sera généré dans le dossier où tu exécutes la commande terminal. (Tu peux entrer `pwd` pour voir le chemin de ton dossier actuel) ```sh Terminal nest new nestjs-superchat # Remplacez "nestjs-superchat" par le nom de votre choix ``` ![Génération d'un nouveau projet NestJS](https://algomax-public.s3.eu-west-3.amazonaws.com/nest_new_7d8e85f568.gif) ## Architecture du projet Avec NestJS, la bonne pratique est de nommer les fichiers en fonction de leur type. Voici les 4 principaux types de fichiers : ### Le service Toute la logique de notre application se trouve dans les services. Modification des données, envoi d'emails, authentification ... Ces fichiers contiennent le plus de lignes de code. Si tu fais un CRUD, tu écriras toute la logique dans un service. Voici le service de base : ```ts app.service.ts import { Injectable } from '@nestjs/common'; @Injectable() export class AppService { getHello(): string { return 'Hello World!'; } } ``` Notez le décorateur `@Injectable()`. NestJS utilise le concept d'**Injection de Dépendances**. Ce décorateur signifie que ce service peut être injecté (et utilisé) dans un autre service. Pour utiliser la méthode `getHello()` , tu vas devoir **injecter** le service _AppService_ à l'intérieur d'un autre service. Tu ne pourras pas "importer" directement la méthode. Je t'en parle plus en détail juste en dessous. ### Le contrôleur Les contrôleur permettent de définir les _routes_. Une route est accessible via une URL. Voici un exemple de contrôleur (j'ai rajouté une route `/posts`) qui est accessible via l'URL `http://localhost:3000/posts` ```ts app.controller.ts import { Controller, Get } from '@nestjs/common'; import { AppService } from './app.service'; @Controller() export class AppController { constructor(private readonly appService: AppService) {} @Get() getHello(): string { return this.appService.getHello(); } @Get('/posts') getPosts(): string { return this.appService.getHello(); } } ``` Après la déclaration de l'_AppController_, tu vois une fonction `constructor`. Elle permet d'injecter le service _AppService_ dans le contrôleur. C'est l'**Injection de Dépendance**. Pour utiliser _AppService_, tu l'injectes dans le constructeur. Si tu utilises **TypeScript**, la syntaxe paraît familière. La méthode `constructor()` sera exécutée à l'initialisation du fichier. Dans cet exemple, elle contient un paramètre `private readonly appService: AppService`. Le mot-clé `private` rend la variable inaccessible de l'extérieur (les fichiers important _AppController_ n'y auront pas accès). Le mot-clé `readonly` rend la variable non modifiable. (Au cas où tu modifies la valeur de `appService` par erreur). Tu accèdes aux méthodes public de _AppService_ via `this.appService`. ### Le Module Le module est le fichier le plus important. Il permet de définir les contrôleurs, les services et potentiellement d'autres modules. Voici un exemple de module : ```ts app.module.ts import { Module } from '@nestjs/common'; import { AppController } from './app.controller'; import { AppService } from './app.service'; @Module({ imports: [], controllers: [AppController], providers: [AppService], }) export class AppModule {} ``` Pour que la route déclarée dans _AppController_ soit accessible, tu as besoin d'importer ton fichier contrôleur dans le module. Le décorateur `@Module` permet de définir les contrôleurs, les services et les modules importés. Par exemple, notre module d'Authentification aura besoin du module **JWT** pour générer des tokens sécurisés. ```ts auth.module.ts import { Module } from '@nestjs/common'; import { JwtModule } from '@nestjs/jwt'; import { JwtStrategy } from './jwt.strategy'; @Module({ imports: [ JwtModule.register({ secret: process.env.JWT_SECRET, signOptions: { expiresIn: '30d', }, }), ], providers: [JwtStrategy], }) export class AuthModule {} ``` ## Aller plus loin avec Algomax - [Développement d'agent IA sur mesure](/services/agent-ia) - [Création d'application SaaS](/services/application-saas) - [Développement d'application mobile](/services/application-mobile) - [Agence IA à Strasbourg](/agence-strasbourg) --- ## Pour aller plus loin Une API solide demande aussi une interface qui tient la route. Si tu construis un produit complet : - Côté front mobile : voir [notre agence application mobile React Native à Strasbourg](/services/application-mobile). - Côté automatisation : un [agent IA WhatsApp pour entreprises](/services/agent-ia-whatsapp) peut déclencher tes endpoints NestJS en temps réel. - Tu lances un SaaS ? Le [guide pratique pour fondateurs](/blog/creer-une-application-saas-le-guide-pratique-pour-fondateurs) couvre la suite. --- ## 8 étapes pour devenir développeur React URL: https://algomax.fr/blog/8-etapes-pour-devenir-developpeur-react Publié le : 2023-07-09 Description : Tu t'intéresses au développement web ou tu as pour ambition d'en faire ton métier ? Je te raconte mon parcours pour devenir développeur fullstack React, Javascript, et toutes les étapes qui m'ont permis d'être totalement autonome. ## Qu'est-ce qu'un développeur web ? Un développeur est un bricoleur qui exploite la technologie pour **résoudre des problèmes** et gagner du temps. Le temps est notre ressource la plus précieuse, et tu peux **vendre** ta compétence. Cette activité exploite ton **ingéniosité**, car il y a **plusieurs moyens de résoudre** et appréhender le même problème. Tu vas réfléchir à des **solutions**, tu vas **muscler** ton cerveau car tu voudras toujours faire mieux. Tu voudras proposer la **meilleure solution possible**. Elle peut être meilleure en terme de **simplicité**, en terme d'argent économisé, en terme de temps gagné et en terme d'efficacité. ## Comment devenir développeur web ? Il faut bien que tu comprennes que monter en compétence **prend du temps** et surtout beaucoup de pratique. Si tu veux voir des résultats, tu vas devoir te mettre au travail. Pour être excellent, il faut **charbonner**, il n'y a pas de secret. Mais il ne faut surtout pas se mettre la pression ou se fixer des objectifs trop compliqués. Faire du développement est avant tout un plaisir, et tu n'as pas envie de te dégoûter du métier. C'est un marathon, tu n'as pas besoin de sprinter et te dépêcher. Tu vas te fatiguer pour rien. **Tu as le temps**. ## Puis-je apprendre le développement et en faire mon métier ? Si tu te pose cette question, la réponse est **oui**. Je fais du développement depuis plus de 5 ans et je vais te raconter mon parcours pour devenir développeur web, et les étapes qui m'ont permis d'être totalement autonome. Allons-y avec la première étape que je recommande à **toute personne qui souhaite se lancer**. ## 1. Maîtriser le terminal La premier conseil que donne à qui veut se lancer, c'est de **comprendre et utiliser son terminal**. Pourquoi donc ? Que tu sois sur téléphone, tablette ou ordinateur, ton appareil est constitué des mêmes pièces : - une carte graphique, - un processeur, - de l'espace de stockage, - de la mémoire, - un écran, - système d'exploitation Pour utiliser l'appareil, tu interagis avec une interface graphique. Le **terminal**, c'est l'interface non-graphique qui te permet d'interagir avec ton appareil. Tout ce que tu peux faire avec l'interface graphique peut être fait via le terminal : _Fermer un onglet_, _vider ta corbeille_, _déplacer des fichiers_ … Et quand **tu vas développer tes premiers programmes**, tu seras amené à beaucoup utiliser le terminal. Pour rentrer des **commandes**, installer les **mises à jours**, etc. Quand tu auras développé ton premier site, tu voudras le mettre en ligne et le partager à tes amis et à ta famille. **Comprendre comment les sites sont mis en ligne** et accessibles au public fera de toi un meilleur développeur. Je te conseille d’installer _Ubuntu_ ou _Linux_, qui est un **système d’exploitation gratuit**. Ils sont utilisés sur la plupart des serveurs qui hébergent les plus grands sites comme _Netflix_ et _YouTube_. ### Comment utiliser le terminal ? Je te donne plusieurs ressources pour apprendre à utiliser ton terminal en installant Ubuntu. Certaines sont gratuites, et d'autres sont payantes. - Tu peux l’installer sur _Windows_ avec [**VirtualBox**](https://www.virtualbox.org/wiki/Downloads) qui va simuler un environnement Ubuntu sur ta machine. C’est parfait si tu as **20** à **30 Go** de stockage pour Ubuntu. - Tu peux aussi t’acheter un deuxième disque dur et installer Ubuntu dessus. Ça te permettra d’alterner entre Windows et Ubuntu et de garder ton environnement Windows clean. - Tu peux aussi installer Ubuntu directement sur Windows sans passer par VirtualBox avec [**WSL2**](https://learn.microsoft.com/fr-fr/windows/wsl/install). Pour ce faire il te faut Windows 10 minimum et le support Hyper-V Virtualization. ## 2. Apprendre la syntaxe HTML et le CSS Maintenant que tu utilises un environnement Linux propice au travail, je te conseille de développer tes premiers sites directement dessus. Et c’est pour plusieurs raisons. Il faut à tout prix **éviter les distractions** pour apprendre de **manière efficace**. Ton cerveau est limité en énergie et si tu utilises beaucoup les réseaux sociaux, tu vas l’épuiser et tu n’auras plus envie de travailler. > Mon conseil : Met ton téléphone en silencieux dans une autre pièce, isole-toi si tu peux à la maison et demande à tes proches de ne pas te déranger. **Et met toi au travail**. Sur l’environnement Linux, tu n’auras pas accès à toutes tes applications, tes jeux vidéos ou barre de favoris sur Google Chrome. Tu limiteras tes chances d’être déconcentré. Maintenant que t'es prêt, tu vas apprendre la syntaxe **HTML et le CSS**. C’est vraiment la base du **développement web**. Il faut que tu **comprennes** comment fonctionnent les sites web. Cette syntaxe est comprise par tous les navigateurs et tu n’as besoin d’installer quoi que ce soit pour l’utiliser. Tu peux ouvrir un bloc note et commencer à coder. Ensuite tu ouvriras le fichier que tu as créé dans ton navigateur, et tu verras le résultat de ton travail. Je te conseille les ressources sur [W3School](https://www.w3schools.com/html/) et surtout, **fixe-toi tes objectifs** pour apprendre et comprendre comment tes sites préférés sont faits. Recopie le design de certains sites, challenge toi sans regarder la solution. Il n’y a pas meilleure manière d’apprendre que de galérer et bloquer sur un objectif avant de trouver la solution à ton problème. **Sois curieux**, n’hésite pas à utiliser ton navigateur pour inspecter le code de tes sites préférés pour mieux comprendre comment ils sont faits. ## 3. Javascript et le serveur Après t’être entraîné en reproduisant tes sites préférés, tu dois avoir une meilleure compréhension de comment un site est construit. Mais il te reste surement une question. Comment est-ce que les sites sont alimentés en données ? Est-ce que le code source est modifié à chaque fois que Netflix rajoute une série ou que ton blogueur écrit un nouvel article ? La réponse est _non_, effectivement car ça serait pas du tout pratique ! L’HTML et le CSS te permettent **d’afficher, de structurer et d’appliquer le design** à ton site. Mais il existe un langage de programmation idéal pour lui donner un peu de peps. Tu vas découvrir ce qu’est la programmation avec **Javascript**, que tu vas utiliser pour ajouter du contenu dynamique à ton site. > Et c’est là que ça devient compliqué et je vais surement te perdre. Tu vas devoir dissocier **ton site web** et le **contenu** de ton site web. Quand tu vas sur Facebook ou sur le site de ton choix, toutes les données comme les _like_, les images et tous les commentaires sont **stockés** dans une **base de donnée** sur un **serveur** distant. Ils n’ont pas été ajoutés dans le code source de Facebook. Et pourtant, au moment où tu charges la page, tu retrouves bien toutes les informations que tu as renseigné. Si on inspecte le code **HTML**, on y retrouve les blocs pour chacun de tes _posts_. C’est la partie du développement qui est pour moi la plus **intéressante**. C’est celle sur laquelle je passe le plus de temps à développer. Tu vas apprendre des nouveaux mots comme **backend**, **frontend**, **API**… Tu vas apprendre à créer des **fonctions**, qui sont des morceaux de **codes réutilisables**, tu vas déclarer des _variables_ et des _constantes_ qui sont des valeurs sous formes de données auxquelles tu auras assigné un nom. La plupart des sites sur internet comme _Amazon_ ou _Spotify_ accèdent à leur donnée depuis une **base de donnée (ou DB)** et un serveur qui contient les autres fichiers comme les images et les musiques. C’est grâce à **Javascript** que tu vas pouvoir récupérer toutes ces données et rajouter le code source sur la page internet au moment du chargement du site par un utilisateur. ## 4. Logique frontend : Récupérer et charger les données depuis un serveur Après avoir mis en place ton premier serveur **Javascript**, tu vas vouloir apprendre à **communiquer** avec ce serveur depuis ta page web. Tu vas utiliser les **formulaires** et les **requêtes HTTP**. Toute communication entre plusieurs serveurs et un site web passent par des requêtes _HTTP_. Tu vas découvrir les nouveaux verbes _GET_, _POST_, _PUT_, _DELETE_, l’_API fetch_ et les _récupérations des données de formulaires_. ## 5. Mettre en place une base de donnée Mais ce n’est pas tout ! Tu vas maintenant apprendre à utiliser une base de données en **SQL**. Tu vas lire et écrire des **schémas de données** et des requêtes au langage **SQL**. Le principe de cette partie n’est pas de tout apprendre mais de **comprendre comment tes données sont stockées**. Par la suite, tu utiliseras un _ORM_ qui te facilitera la tâche. En Javascript, j’utilise [_Prisma_](https://www.prisma.io/) qui simplifie grandement la gestion d'une base de donnée. ## 6. Apprendre React -- ou n'importe quel framework En tant que développeur, on n’est jamais satisfait de son travail. On trouvera toujours quelque chose à faire en plus ou à améliorer. On aime bien se compliquer la vie. Et souvent, si tu reviens sur du code que que tu as produit il y a 6 mois, tu vas gerber. Tu auras honte du code que tu as produit. Tu voudras refactoriser ton code, l’améliorer, le renforcer et le rendre plus lisible. Tu peux aussi rajouter des commentaires pour aider ton futur-toi à comprendre ce que tu as voulu faire. C’est tout à fait normal dans le cycle de vie de notre base de code. A chaque apprentissage, tu vas et tu dois mettre en pratique ce que tu as appris. Il est temps maintenant que tu prennes connaissance des framework et des librairies qui facilitent le développement de site web. Tu as peut-être déjà entendu parler de **VueJS** ou de **React** qui sont les plus connus. Il y a aussi **Svelte**, **Qwik** et **SolidJS**. Et j’en oublie plein d’autres. On va pas se le cacher, la librairie qui intéresse le plus les entreprises à l’heure actuelle, c’est **React**. C’est celle qui **embauche le plus** d’après les milliers d’offres d’emploi. **React** nous permet d’écrire une syntaxe qui ressemble à de l’** HTML ** et à du **Javascript** dans le même fichier. Cette technologie te permet de développer des morceaux d’interface personnalisable et répétable. En HTML, il n’y a aucun moyen d’écrire la logique qu’une seule fois. Par exemple pour afficher un blog avec trois articles, tu vas devoir copier coller la syntaxe complète de l’article trois fois. React répond à ce problème et bien plus encore car il nous permet de créer des interfaces totalement dynamiques avec sa gestion d’état qu’on appelle le **state**. ## 7. React est mieux avec un framework React ne répond malheureusement pas à tous nos besoins. Pour faire un site complet, nous avons besoin de gérer le **routing**, qui est la navigation entre plusieurs pages du même site. Quand tu navigues sur un site et que tu changes de page, l’adresse URL du site va changer aussi. En fonction de cette adresse, le site sait quelle page t’afficher. C’est ce qu’on appelle le routing. Il y a plein d’autres éléments que **React** ne permet pas de traiter, et c’est pour ça que nous allons utiliser un framework en supplément de React. Il y en a plusieurs sur le marché comme **NextJS** et **Remix**. J’utilise **Remix** depuis maintenant deux ans et je le trouve **beaucoup plus lisible** et **simple d’utilisation** que NextJS. Au sein de notre base de code, nous allons pouvoir afficher la vue de notre site, c’est à dire l’interface visuelle. Mais nous allons aussi développer la logique de notre serveur et nos API. Cette logique se situe par défaut dans le même fichier, et je trouve que c’est beaucoup plus clair. Quand j’ai appris le développement, je faisais mes premiers sites en React et je développais un serveur dans un nouveau projet avec un code source totalement différent. Cela signifie qu’il faut alterner entre deux dossiers, deux syntaxes différentes et parfois même un langage différent. Avec **Remix**, si je veux créer un blog, je vais coder toute ma logique dans le même fichier. Je vais d’abord charger mes articles en créant une nouvelle API. Puis je vais les afficher dans mon composant React, qui va s’occuper du rendu visuel. C’est ce que les visiteurs de mon blog verront. ## 8. Versioning et déploiement Après avoir développé ton site internet, tu seras tellement fier que tu voudras le montrer à tes amis ou à ta famille. Tu ne vas pas **conserver le code source sur ton ordinateur définitivement**. Tu vas le **mettre en ligne** quelque part pour qu’il soit accessible sur internet et visible au public. Rassure-toi, personne ne va voir ton code source. Tu vas l’héberger sur **Github** à chaque mise à jour. Si tu travailles pour une entreprise en tant que développeur, ils vont t’assigner différentes tâches. Tu vas donc télécharger le code source du site sur ton ordinateur, et tu vas le modifier pour répondre au besoin de ta boîte. Une fois que tu as terminé ta tâche, tu vas mettre à jour le code source sur une plateforme d’hébergement de code comme Github ou Gitlab. A partir de là, toi ou tes collègues pourront mettre à jour le site public avec les changements que tu as apporté. Et ça sera pareil pour ton site. C’est notamment pour ça que tu as besoin de t’y connaître en utilisation de terminal et de Linux. Tu vas héberger ton site sur un serveur distant qui utilisera surement ce système d’exploitation. ## Conclusion C’étaient les 8 conseils que je donnerai à un ami qui veut se lancer en tant que développeur web. J’espère que ça t’a plu et que ça ta donné envie de te lancer. Si tu t’es déjà lancé bravo à toi, je te souhaite beaucoup de succès. --- ## Mettre à jour son application Node.js avec npm-check-updates URL: https://algomax.fr/blog/comment-mettre-a-jour-son-application-nodejs-facilement-avec-npm-check-updates Publié le : 2023-07-02 Description : Méthode simple et sûre pour mettre à jour les dépendances Node.js avec npm-check-updates sans casser la prod. > Mise à jour SEO (Mars 2026) > > Ce guide vous donne une procédure pragmatique pour faire évoluer les dépendances Node.js, tester les impacts et réduire le risque en production. ## Présentation de NPM Check updates [NPM Check Updates](https://www.npmjs.com/package/npm-check-updates) est une commande permettant de mettre à jour les packages de votre application nodeJS. Lancez-là dans votre dossier projet et elle vous proposera de mettre à jour les packages obsolètes. ## Pré-requis - NodeJS ## Comment installer NPM Check Updates en global ? Pour utiliser le package dans tous vos projets, il est recommendé de l'installer en _global_. Pour ce faire, ouvrez votre terminal et lancez la commande suivante : ```bash Terminal npm install -g npm-check-updates ``` ## Comment utiliser NPM Check Updates ? Après avoir installé la librairie, vous devez vous rendre dans votre dossier projet contenant un fichier `package.json`. Sans cela, la commande ne fonctionnera pas. Une fois dans votre dossier, lancez la commande suivante : ```bash Terminal ncu -i --format group ``` - L'argument -i permet de rendre la commande interactive. Vous pourrez ainsi choisir les packages à mettre à jour. - L'argument --format group permet de regrouper les packages par type (dependencies, devDependencies, etc.). ![NPM Check Updates](https://algomax-public.s3.eu-west-3.amazonaws.com/npm_check_updates_577aedf53a.png) Vous pouvez sélectionner et déselectionnez la liste des package que vous souhaitez mettre à jour. Voici la liste des commandes complètes du terminal interactif : - flèche du haut : sélectionner le package précédent - flèche du bas : sélectionner le package suivant - espace : sélectionner/déselectionner le package - a : sélectionner tous les packages - i : inverser la sélection - r : revenir à la liste des packages - q : quitter - Entrée : valider la sélection Une fois la sélection validée, la librairie liste le récapitulatif des modifications apportées au fichier `package.json`. Il vous demande si vous souhaitez mettre à jour votre projet tout de suite. Appuyez sur Y pour confirmer. ![Récapitulatif des package installés via NPM Check Updates](https://algomax-public.s3.eu-west-3.amazonaws.com/npm_check_updates_install_8d4b0fbc62.png) ## Vérifier le comportement de votre projet Après avoir mis à jour votre application, je vous recommande de la lancer et d'effectuer quelques tests manuels pour vérifier que tout fonctionne correctement. ## Comment faire si une mise à jour casse mon application ? Tant que vous n'avez pas push le code modifié sur votre dépôt git, vous pouvez annuler les modifications apportées par NPM Check Updates. ## Conclusion NPM Check Updates est une librairie très pratique que j'utilise souvent pour mettre à jour mon projet ! J'espère qu'elle vous sera utile ! ## Aller plus loin avec Algomax - [Développement d'agent IA sur mesure](/services/agent-ia) - [Création d'application SaaS](/services/application-saas) - [Développement d'application mobile](/services/application-mobile) - [Agence IA à Strasbourg](/agence-strasbourg) --- ## Pour aller plus loin Maintenir ton app, c'est une chose. La livrer en prod, c'en est une autre : - [Créer une application mobile en 2026](/blog/guide-complet-de-la-conception-d-une-application-mobile-de-a-a-z) — le guide pour fondateurs. - Une [agence application mobile React Native](/services/application-mobile) peut prendre le relais si tu manques de temps. - Agence complète dev mobile, web et IA : [algomax.fr à Strasbourg](/agence-strasbourg). --- ## Certificat SSL expiré avec Caddy: diagnostic et correctif URL: https://algomax.fr/blog/comment-reparer-l-erreur-certificate-has-expired-avec-caddy-server Publié le : 2023-06-06 Description : Résolvez rapidement l’erreur certificate has expired avec Caddy Server: diagnostic, causes fréquentes et procédure de correction. > Mise à jour SEO (Mars 2026) > > Cette mise à jour détaille un playbook court pour restaurer votre HTTPS sous Caddy sans tâtonner. # Certificat SSL expiré avec Caddy Server : comment le réparer Vous ouvrez votre site web et le navigateur affiche un avertissement de sécurité. "Certificate has expired." Le petit cadenas dans la barre d'adresse est barré en rouge. Vos visiteurs voient un message effrayant qui leur déconseille de continuer. Pas idéal pour la crédibilité de votre entreprise. Si vous utilisez Caddy Server, ce problème ne devrait normalement jamais arriver. Caddy gère automatiquement vos certificats SSL. Pourtant, dans certaines configurations cloud (notamment sur AWS), un détail de configuration réseau peut tout bloquer. Voici comment identifier le problème et le corriger en quelques minutes. ## SSL et HTTPS, c'est quoi exactement ? Quand vous visitez un site dont l'adresse commence par `https://`, la connexion entre votre navigateur et le serveur est chiffrée. Personne ne peut intercepter les données échangées (mots de passe, coordonnées bancaires, formulaires). Le certificat SSL, c'est ce qui prouve que le chiffrement est en place. C'est lui qui fait apparaître le petit cadenas dans votre navigateur. Quand ce certificat expire, le navigateur considère que la connexion n'est plus sûre et bloque l'accès au site. ## Caddy Server : le renouvellement automatique qui s'arrête Caddy est un serveur web moderne. Son principal avantage : il obtient et renouvelle automatiquement les certificats SSL via Let's Encrypt, une autorité de certification gratuite. En théorie, vous n'avez rien à faire. Caddy s'occupe de tout. Mais pour que le renouvellement fonctionne, Let's Encrypt doit pouvoir communiquer avec votre serveur. C'est là que ça peut coincer. ## Diagnostic : vérifier l'état du certificat Commencez par vérifier la date d'expiration de votre certificat depuis votre serveur : ```bash echo | openssl s_client -connect votre-domaine.com:443 2>/dev/null | openssl x509 -noout -dates ``` Cette commande affiche deux dates : - `notBefore` : date de création du certificat - `notAfter` : date d'expiration Si la date `notAfter` est passée, votre certificat a bien expiré. Ensuite, regardez les logs de Caddy pour comprendre pourquoi le renouvellement a échoué : ```bash docker logs caddy --tail 100 ``` Cherchez des lignes contenant `certificate`, `renewal`, `failed` ou `challenge`. ## La cause la plus fréquente : le pare-feu bloque Let's Encrypt Let's Encrypt utilise un processus de validation pour prouver que vous contrôlez bien le domaine. Il envoie une requête vers votre serveur sur les ports 80 (HTTP) ou 443 (HTTPS). Sur AWS, les Security Groups contrôlent quel trafic peut atteindre votre serveur. Si les ports 80 et 443 ne sont pas ouverts au trafic entrant depuis toutes les adresses IP, Let's Encrypt ne peut pas valider votre domaine. Le renouvellement échoue silencieusement. ## La solution ### 1. Ouvrir les ports dans AWS Security Groups Accédez à la console AWS, puis EC2, puis Security Groups. Trouvez le groupe de sécurité associé à votre instance et ajoutez ces règles entrantes : | Type | Port | Source | |-------|------|-----------| | HTTP | 80 | 0.0.0.0/0 | | HTTPS | 443 | 0.0.0.0/0 | Les deux ports doivent être ouverts. Même si votre site fonctionne uniquement en HTTPS, le port 80 est souvent utilisé par Let's Encrypt pour la validation. ### 2. Forcer le renouvellement du certificat Une fois le pare-feu corrigé, relancez Caddy : ```bash docker restart caddy ``` Vérifiez les logs pour confirmer que le renouvellement a fonctionné : ```bash docker logs caddy --tail 50 ``` ### 3. Vérifier le résultat ```bash echo | openssl s_client -connect votre-domaine.com:443 2>/dev/null | openssl x509 -noout -dates ``` La date `notAfter` devrait maintenant être dans environ 90 jours. ## Éviter que ça se reproduise - **Ne touchez pas aux ports 80 et 443.** Gardez-les ouverts pour la validation Let's Encrypt. - **Surveillez vos certificats.** Des outils comme UptimeRobot ou Better Stack peuvent vous alerter avant l'expiration. - **Testez après chaque modification réseau.** Un changement de Security Group peut casser le renouvellement sans que vous le remarquiez immédiatement. ## Vous préférez ne pas gérer tout ça vous-même ? La gestion des serveurs, des certificats SSL et des configurations réseau, ça prend du temps. Chez Algomax, nous gérons l'hébergement et le déploiement de vos applications. Certificats SSL, mises à jour, monitoring : tout est inclus. [Contactez-nous](/contact) pour en discuter. ## Aller plus loin avec Algomax - [Développement d'agent IA sur mesure](/services/agent-ia) - [Création d'application SaaS](/services/application-saas) - [Développement d'application mobile](/services/application-mobile) - [Agence IA à Strasbourg](/agence-strasbourg) --- ## Docker: synchroniser l’heure du serveur et du conteneur URL: https://algomax.fr/blog/comment-synchroniser-l-heure-du-serveur-avec-docker Publié le : 2023-05-23 Description : Corrigez les décalages de fuseau horaire dans Docker avec une configuration propre et vérifiable en production. > Mise à jour SEO (Mars 2026) > > Vous voyez des timestamps incohérents ? Ce tuto montre comment aligner timezone serveur/conteneur pour fiabiliser logs, jobs et données. # Docker : comment synchroniser l'heure du serveur avec votre conteneur Votre application affiche 14h00 alors qu'il est 16h00. Les dates de création dans votre base de données sont décalées de deux heures. Vos emails automatiques partent au mauvais moment. Le problème ne vient pas de votre code. Il vient de Docker. ## Docker, en quelques mots Docker est un outil qui permet d'empaqueter une application avec tout ce dont elle a besoin pour fonctionner : le code, les dépendances, la configuration. Le tout tourne dans un "conteneur", une sorte de boîte isolée. L'avantage : votre application se comporte de la même façon sur votre ordinateur, sur un serveur de test et en production. Mais cette isolation a un effet secondaire. Le conteneur a sa propre horloge. Et par défaut, elle n'est pas réglée sur le même fuseau horaire que votre serveur. ## Pourquoi les heures sont décalées Par défaut, tous les conteneurs Docker utilisent le fuseau horaire UTC (Coordinated Universal Time). C'est le fuseau de référence mondial, celui de Londres en hiver. La France est en UTC+1 (heure d'hiver) ou UTC+2 (heure d'été). Si votre serveur est configuré en heure française mais que votre conteneur reste en UTC, vous aurez un décalage d'une à deux heures sur toutes les dates et heures. Vous pouvez le vérifier facilement : ```bash docker exec -it nom_du_conteneur date ``` Comparez avec l'heure de votre serveur : ```bash date ``` Si les deux ne correspondent pas, c'est bien un problème de fuseau horaire. ## Solution 1 : configurer le fuseau dans le Dockerfile Si vous construisez votre propre image Docker, ajoutez ces lignes dans votre `Dockerfile` : ```dockerfile ENV TZ=Europe/Paris RUN ln -snf /usr/share/zoneinfo/$TZ /etc/localtime && echo $TZ > /etc/timezone ``` La première ligne définit la variable d'environnement `TZ` sur le fuseau horaire de Paris. La seconde crée un lien vers le bon fichier de fuseau horaire dans le conteneur. Reconstruisez ensuite votre image : ```bash docker build -t mon-application . ``` Puis relancez votre conteneur. L'heure devrait maintenant correspondre à l'heure française. ## Solution 2 : passer par docker-compose Si vous utilisez Docker Compose (un outil qui permet de gérer plusieurs conteneurs avec un seul fichier de configuration), vous pouvez monter le fichier de fuseau horaire du serveur directement dans le conteneur : ```yaml services: mon-application: image: mon-application:latest environment: - TZ=Europe/Paris volumes: - /etc/localtime:/etc/localtime:ro ``` Le volume `/etc/localtime:/etc/localtime:ro` copie la configuration horaire du serveur hôte dans le conteneur. Le `:ro` signifie "read-only" (lecture seule). ## Quelle solution choisir ? Le **Dockerfile** est préférable si vous voulez que le fuseau horaire soit toujours le même, peu importe le serveur. Le **docker-compose** avec le volume est préférable si vous déployez sur plusieurs serveurs dans des fuseaux horaires différents. Dans la plupart des cas, pour une application française hébergée en France, la solution Dockerfile est la plus simple. ## Vérification Après avoir appliqué le correctif : ```bash docker exec -it nom_du_conteneur date ``` Vous devriez voir l'heure française. Vérifiez aussi dans votre application que les dates sont maintenant correctes. ## Vous ne voulez pas gérer ces détails d'infrastructure ? La configuration Docker, les fuseaux horaires, le déploiement, la maintenance... ce sont des sujets techniques qui prennent du temps. Chez Algomax, nous déployons et maintenons les applications de nos clients sur des infrastructures Docker. [Parlons de votre projet](/contact). ## Aller plus loin avec Algomax - [Développement d'agent IA sur mesure](/services/agent-ia) - [Création d'application SaaS](/services/application-saas) - [Développement d'application mobile](/services/application-mobile) - [Agence IA à Strasbourg](/agence-strasbourg) --- ## Pour aller plus loin Une fois ton serveur Docker bien réglé, deux directions : - Déployer une app JS complète ? Le guide [Docker + GitHub Actions + Caddy sur un VPS](/blog/deployer-application-javascript-vps-docker-github-actions-caddy). - Livrer une app mobile en 4 semaines : [agence application mobile React Native](/services/application-mobile). - Un agent IA qui tourne 24/7 : [agent IA WhatsApp pour entreprises](/services/agent-ia-whatsapp). --- ## Gérer son contenu statique avec Strapi CMS URL: https://algomax.fr/blog/gerer-son-contenu-statique-avec-strapi-cms Publié le : 2023-04-01 Description : Quand je développe des sites internet, je souhaite qu'ils soient référencés avec le rendu côté serveur (SSR). Dois-je forcément coder mon contenu en dur ? Non, nous pouvons utiliser des CMS pour charger ces données. ## Gérer le contenu d'un site sur mesure avec Strapi [**Strapi**](https://strapi.io/) est un *CMS* (Content Management System) basé sur [Node.js](/blog?category=nodejs). Nous l'utilisons chez [Algomax](/) pour gérer nos contenus (comme les articles de notre [blog](/blog) ou les textes de la [page d'accueil](/). L'outil est simple à prendre en main et peut être utiliser par des non-développeurs. Il facilite le développement d'applications en fournissant une interface simple pour administrer vos contenus. ### Nous utilisons Strapi pour le SEO Ce CMS a un avantage : Il nous permet de charger des données **côté serveur**. Découvrez comment nous utilisons Strapi chez Algomax dans cette courte vidéo. --- ## Comment différer le chargement des données en React ? URL: https://algomax.fr/blog/comment-differer-le-chargement-des-donnees-en-react Publié le : 2023-03-10 Description : Avant React 18, il n'y avait que deux moyens de charger les données. Côté client, et côté serveur. Avec le framework Remix, un troisième type de chargement est possible grâce au streaming. ## Comment activer le chargement différé des données avec Remix (defer) En développant une application React, vous avez surement déjà eu avoir à charger des données depuis une API externe. Pour ce faire, plusieurs solutions s'offrent à vous : - les charger côté client (dans un **useEffect**) - les charger côté serveur (avec un framework comme **Remix** ou **NextJS**) Mais il existe une troisième option (si vous utilisez **Remix**) : Déclencher le chargement des donnés côté serveur, mais ne pas attendre la réponse du serveur pour afficher la page à l'utilisateur. Découvrons comment avec des exemples : ### Chargement côté client Voici la syntaxe pour des données côté client ```tsx index.tsx import { useEffect, useState } from 'react'; type UserType = { id: number; email: string }; const loadUsers = async () => { const response = await fetch('https://jsonplaceholder.typicode.com/users'); const users = (await response.json()) as UserType[]; return users; }; const Component = () => { const [users, setUsers] = useState([]); useEffect(() => { loadUsers().then((data) => setUsers(data)); }, []); return (
    {users.map((user) => (
  • {user.email}
  • ))}
); }; ``` On affiche une liste d'utilisateurs, suite à un appel à l'API de [JsonPlaceholder](https://jsonplaceholder.typicode.com). Comme le chargement se fait côté client, la page va se charger très vite. Cependant, le visiteur ne verra pas tout de suite la liste des utilisateurs. Il faut attendre que l'API externe envoie une réponse positive, contenant la donnée. Il y aura ensuite du [**Cumulative Layout Shift (CLS)**](https://web.dev/articles/cls). Au chargement de la donnée, la liste va s'afficher et les éléments en dessous de la liste seront décallés vers le bas. Certaines applications affichent même des indicateurs de chargement pour expliquer au visiteur qu'il y aura bientôt la donnée. ![](https://static.vaadin.com/directory/userBrightspaceUI/screenshot/file1092438482345896051_1541426373537loading-spinner-screenshot") Pour remédier à ce problème, il suffit de charger la donnée côté serveur. Elle apporte trois améliorations : - Plus besoin d'afficher d'indicateur de chargement - Plus besoin de gérer la logique de chargement des données côté client - Pas de **CLS** (La liste aura toujours été là, il n'y aura plus de décallage ### Chargement côté serveur avec Remix Pour charger notre liste côté serveur en utilisant [Remix](https://remix.run), il suffit de déplacer la logique de chargement dans une méthode **loader**. ```tsx index.tsx import { json } from '@remix-run/node'; import { useLoaderData } from '@remix-run/react'; type UserType = { id: number; email: string }; const loadUsers = async () => { const response = await fetch('https://jsonplaceholder.typicode.com/users'); const users = (await response.json()) as UserType[]; return users; }; export const loader = async () => { const users = await loadUsers(); return json(users); }; const Component = () => { const users = useLoaderData(); return (
    {users.map((user) => (
  • {user.email}
  • ))}
); }; export default Component; ``` Nous utilisons ensuite le hook spécial de Remix, [useLoaderData](https://remix.run/docs/en/main/hooks/use-loader-data) pour récupérer les données renvoyées par le serveur (suite à l'exécution de la méthode **loader**). Malgré les avantages énumérés plus haut, cette optimisation nous rajoute un inconvénient : > Nous devons attendre que les données soient chargées avant d'afficher la page. Le visiteur devra attendre plus longtemps devant une page blanche. Sauf que l'équipe de développement de **Remix** y a pensé. Nous pouvons utiliser la méthode **defer** pour les requêtes *lentes* et *secondaires*. ### Implémenter le chargement différé de Remix Pour charger nos données en différé, nous avons besoin de remplacer la méthode **json** de Remix par une méthode **defer*. De plus, au lieu d'utiliser *await* pour attendre le chargement de la donnée directement, nous l'appelons sans le mot-clé. Cela signifie que n'attendons pas la réponse de l'API avant de renvoyer notre donnée. ```tsx index.tsx import { defer } from '@remix-run/node'; import { Await, useLoaderData } from '@remix-run/react'; import { Suspense } from 'react'; type UserType = { id: number; email: string }; const loadUsers = async () => { const response = await fetch('https://jsonplaceholder.typicode.com/users'); const users = (await response.json()) as UserType[]; return users; }; export const loader = async () => { const usersPromise = loadUsers(); return defer({ usersPromise }); }; const Component = () => { const { usersPromise } = useLoaderData(); return ( Chargement des utilisateurs}> Erreur lors du chargement des utilisateurs} > {(users) => (
    {users.map((user) => (
  • {user.email}
  • ))}
)}
); }; export default Component; ``` Nous avons également utilisé le composant **Suspense**, qui est nécessaire pour utiliser le chargement différé. Analysons maintenant la syntaxe du composant **Await**. Durant le chargement des données, le composant **Suspense** affiche un message de chargement (déclaré dans le prop *fallback*). Une fois le chargement terminé, le composant **Await** qui reçoit en prop notre promesse *usersPromise* va nous afficher le composant enfant : notre liste d'utilisateurs. [Regardez-là sur YouTube dès maintenant !](https://youtu.be/Zsi6gbFgFGA) --- ## Transformer des données d'API en CSV avec NodeJS URL: https://algomax.fr/blog/transformer-des-donnees-d-api-en-csv-avec-node-js Publié le : 2023-02-23 Description : Les fichiers CSV représentent un format de donnée très courant sur internet. Dans cet article, nous allons lire et convertir les données d'une API JSON vers un fichier CSV téléchargable avec Node.JS J'ai récemment eu besoin de manipuler des données CSV avec NodeJS. Dans cet article, je vous propose de convertir les données d'une API en fichier CSV. J'utilise l'exemple d'une API, mais vous pouvez utiliser des données provenant d'une base de données. Nous utiliserons [csv-stringify](https://www.npmjs.com/package/csv-stringify) qui répond totalement à notre besoin. [Retrouvez le guide vidéo sur YouTube !](https://youtu.be/FLcW2wbf4Y4) ### Pré-requis - [node.js](https://nodejs.org/en/) installé ## Configurer notre projet NodeJS Nous allons générer une nouvelle application node.js afin de pouvoir installer la librairie *csv-stringify*. Pour ce faire, ouvrez votre terminal dans un dossier vite, et entez la commande suivante. Cela va créer un fichier `package.json`. ```bash mkdir json-to-csv # Commande optionnelle pour créer un nouveau dossier vide cd json-to-csv # Commande optionnelle pour entrer dans le dossier créé npm init -y ``` Il faut également modifier le fichier *package.json* et y copier la ligne `"type":"module"`. Voici à quoi ressemble un fichier bien configuré : ```json { "name": "json-to-csv", "version": "1.0.0", "description": "", "main": "index.js", "type": "module", "scripts": { "test": "echo \"Error: no test specified\" && exit 1" }, "keywords": [], "author": "", "license": "ISC", "dependencies": { } } ``` Nous avons terminé la configuration. Nous pouvons maintenant créer un nouveau fichier `server.js` qui va contenir le code source. Je vous conseille de l'ouvrir avec votre éditeur de code préféré (je recommande d'utiliser [VSCode](https://code.visualstudio.com/)). ## Récupération de la donnée API Pour pouvoir transformer notre donnée, nous devons d'abord la récupérer. J'utilise le site [JSON Placeholder](https://jsonplaceholder.typicode.com/) qui met à disposition des fausses données destinées à prototyper des projets. Nous allons écrire une première fonction afin de récupérer une liste de *posts* grâce à la librairie *fetch* de Node. J'appelle ma fonction `getPosts`, elle est asynchrone et va utiliser `fetch` pour récupérer nos données depuis JSON Placeholder. Si vous utilisez la version 18 de Node ou supérieur, la librairie `fetch` est maintenant implémentée par défaut. J'utilise la version 16.7, et la librairie `fetch` n'est pas native à Node.JS. Nous devons la télécharger et l'importer dans notre application. Ouvrez votre terminal, et lancez la commande suivante : ```bash npm install node-fetch ``` Il suffit maintenant d'importer fetch à l'intérieur du fichier `server.js`. ```javascript /* server.js */ import fetch from 'node-fetch'; /* La librairie fetch n'est pas native à NodeJS dans la version 16.7 */ export const getPosts = async () => { /* Requête AJAX permettant de récupérer nos données */ const response = await fetch('https://jsonplaceholder.typicode.com/posts'); /* Nous convertissons la réponse en JSON */ const posts = await response.json(); /* Nous vérifions la récupération de notre donnée */ console.log(posts); /* Nous renvoyons un tableau de posts */ return posts; }; // N'oublions pas d'appeler la méthode pour s'assurer qu'elle fonctionne ! getPosts(); ``` Après avoir sauvegardé notre fichier, nous allons exécuter le code avec la commande `node server.js`. Nous devrions voir un tableau de `posts` dans notre terminal. Cela signifie que le projet est bien configuré ! ## Création de notre première route avec ExpressJS Nous voulons pouvoir télécharger un fichier CSV depuis notre navigateur. Nous allons mettre en place plusieurs routes avec le serveur [ExpressJS](https://www.npmjs.com/package/express). Pour ce faire il suffit d'installer la librarie. Entrez la commande suivante dans votre invité de commande : ```bash npm i express ``` Express nous permet de définir des *routes* pour accéder à nos données sous forme d'API. Une route est un chemin d'accès qui associe une URL et une méthode à une action spécifique de l'application. Nous allons tout de suite créer notre première route `/posts` en *GET* pour pouvoir y accéder avec notre navigateur à l'adresse `localhost:3000/posts`. La documentation officielle d'Express nous donne une base de code à exploiter. Nous allons le modifier légèrement. ```javascript import express from 'express'; const app = express(); app.get('/posts', async function (req, res) { const posts = await getPosts(); res.send(posts); }); app.listen(3000); ``` Ci-dessus, nous importons la librarie `express`. - Nous créons une instance d'express dans la variable `app`. - Nous créons ensuite une route de type *GET*, à l'URL `/posts` - La fonction de rappel est asynchrone. Nous devons attendre de récupérer les données depuis notre API avant de pouvoir les traiter - Nous renvoyons la donnée telle quel sous forme de réponse avec la ligne `res.send(posts);`. - Nous demandons finalement à Express d'écouter les requêtes sur le port 3000 Nous pouvons modifier notre fichier `server.js` en conséquence : ```javascript /* server.js */ import express from 'express'; const app = express(); app.get('/posts', async function (req, res) { const posts = await getPosts(); res.send(posts); }); app.listen(3000); export const getPosts = async () => { const response = await fetch('https://jsonplaceholder.typicode.com/posts'); const posts = await response.json(); return posts; }; ``` ## Convertir la donnée en CSV ### Présentation de csv-stringify Nous venons de créer notre première route avec Express ! Mais cela ne répond pas encore à notre besoin. Nous souhaitons télécharger un fichier au format CSV correspondant à notre modèle de données. Nous avons besoin de télécharger une librairie supplémentaire pour effectuer la conversion. Nous pouvons installer *csv-stringify* dans notre terminal avec la commande suivante : ```bash npm i csv-stringify ``` Une fois installé, il est important de relancer notre serveur Express. La [documentation officielle](https://www.npmjs.com/package/csv-stringify#Example) de csv-stringify nous donne une base de code suffisante pour notre besoin : ```javascript import { stringify } from 'csv-stringify/sync'; const output = stringify([ [ '1', '2', '3', '4' ], [ 'a', 'b', 'c', 'd' ] ]); ``` Il suffit d'importer la méthode `stringify` depuis `csv/stringify/sync` et de passer en paramètre un tableau de données. Une fois les données converties au format *csv*, nous devons les renvoyer à l'utilisateur grâce à une nouvelle route Express. ### Création d'une nouvelle route En dessous de notre première route, nous allons déclarer une deuxième route qui sera liée à l'URL `/posts/csv`. ```javascript app.get('/posts/csv', async function (req, res) { const posts = await getPosts(); /* Récupération des données depuis notre API */ /* Conversion de notre object clé-valeur en ligne au format CSV */ const postsInCsv = stringify(posts, { header: true, }); /* L'en-tête Content-Type permet d'informer le navigateur du type de contenu */ res.setHeader('Content-Type', 'text/csv'); /* L'en-tête Content-Disposition permet de choisir la disposition de contenu : sous forme de page, ou sous forme de fichier */ res.setHeader('Content-Disposition', 'attachment; filename=posts.csv'); res.send(postsInCsv); }); ``` Revenons sur le code ci-dessus : - Nous déclarons une nouvelle route à l'URL `/posts/csv` avec la méthode *GET* - La fonction de rappel est asynchrone - Nous obtenons la donnée de posts depuis l'API, que nous sauvegardons dans une variable `post` avec l'instruction `const posts = await getPosts()` - Nous utilisons `csv-stringify` pour convertir notre object clé-valeur en valeurs séparées par des virgules. - La méthode `stringify` accepte un premier paramètre qui sera notre donnée de posts, et un tableau optionnel d'options. Nous souhaitons afficher l'en-tête dans le fichier CSV. Par défaut, l'en-tête sera les clés de notre object clé-valeur. - Avant de renvoyer la réponse au navigateur, nous spécifions un type de contenu grâce à l'en-tête `Content-Type` qui prend la valeur `text/csv` - L'en-tête `Content-Disposition` permet de changer la disposition du contenu : Accéder à la route ne va pas afficher une page, mais va à la place télécharger un fichier `posts.csv` - Nous pouvons ensuite renvoyer la réponse ## Code complet Voici le code complet que nous venons de développer : ```javascript import fetch from 'node-fetch'; import { stringify } from 'csv-stringify/sync'; import express from 'express'; const app = express(); app.get('/posts', async function (req, res) { const posts = await getPosts(); res.send(posts); }); app.get('/posts/csv', async function (req, res) { const posts = await getPosts(); const postsInCsv = stringify(posts, { header: true, }); res.setHeader('Content-Type', 'text/csv'); res.setHeader('Content-Disposition', 'attachment; filename=posts.csv'); res.send(postsInCsv); }); app.listen(3000); export const getPosts = async () => { const response = await fetch('https://jsonplaceholder.typicode.com/posts'); const posts = await response.json(); return posts; }; ``` En résumé, nous avons chargé des données *API* avec JSONPlaceholder. Nous avons eu besoin d'installer la librairie fetch qui n'est pas native avant la version 18 de NodeJS. Nous utilisons la librairie *ExpressJS* pour créer des routes afin d'accéder à nos données depuis le navigateur. Nous transformons nos données JSON au *format CSV* avec la librairie `csv-stringify`, que nous renvoyons ensuite au navigateur au format CSV. Nous donnons l'instruction au navigateur de télécharger le fichier avec l'en-tête `Content-Disposition`. Nous avons réussi la conversion de notre donnée d'API JSON en fichier CSV téléchargeable ! J'espère que ce guide vous a été utile. Merci aux contributeurs du [projet](https://csv.js.org/) qui proposent également d'autres librairies, permettant de manipuler davantage de fichiers CSV. --- ## Comment importer un fichier CSV avec nodeJS ? URL: https://algomax.fr/blog/comment-importer-un-fichier-csv-avec-nodejs Publié le : 2023-02-13 Description : Les fichiers CSV représentent un format de donnée très courant sur internet. Dans cet article, nous allons lire et convertir les données d'un fichier en JSON avec Node.JS J'ai récemment eu besoin d'extraire les données d'un fichier CSV pour les persister en base de données. On avait besoin de les exploiter sur une application web, et les récupérer via une API nous paraissait plus simple que lire le fichier CSV à chaque requête. J'ai découvert la librairie [csv-parser](https://www.npmjs.com/package/csv-parser) qui m'a permi de convertir mon fichier CSV en JSON assez rapidement. ## Pré-requis - [node.js](https://nodejs.org/en/) installé - créer un fichier CSV à transformer sur [Mockaroo](https://www.mockaroo.com/) ## Configurer notre projet NodeJS Nous allons générer une nouvelle application node.js afin de pouvoir installer la librairie _csv-parser_. Pour ce faire, ouvrez votre terminal dans un dossier vite, et entez la commande suivante. Cela va créer un fichier `package.json`. ```bash Terminal mkdir csv-to-json # Commande optionnelle pour créer un nouveau dossier vide cd csv-to-json # Commande optionnelle pour entrer dans le dossier créé npm init -y ``` Il faut également modifier le fichier _package.json_ et y copier la ligne `"type":"module"`. Voici à quoi ressemble un fichier bien configuré : ```json package.json { "name": "csv-to-json", "version": "1.0.0", "description": "", "main": "index.js", "type": "module", "scripts": { "test": "echo \"Error: no test specified\" && exit 1" }, "keywords": [], "author": "", "license": "ISC", "dependencies": { "csv-parser": "^3.0.0" } } ``` Nous avons terminé la configuration. Nous pouvons maintenant créer un nouveau fichier `index.js` qui va contenir le code source permettant de transformer nos données CSV en JSON. Je vous conseille de l'ouvrir avec votre éditeur de code préféré (je recommande d'utiliser [VSCode](https://code.visualstudio.com/)). ## Première ligne de code Pour pouvoir lire notre fichier CSV, il faut d'abord le télécharger ! Je suis allé sur le site [Mockaroo](https://www.mockaroo.com/) pour générer un fichier `MOCK_DATA.csv` que j'ai glissé-déposé dans le dossier projet. Nous allons écrire une première fonction afin de détecter la présence du fichier CSV grâce à la librairie native de Node, _fs_. La fonction `readCsvFile` affichera `hello world` dans notre terminal et importera la librairie `fs`. Nous appelons ensuite la fonction pour l'exécuter. ```javascript index.js import fs from 'fs'; export const readCsvFile = () => { console.log('hello world'); }; readCsvFile(); ``` Après avoir sauvegardé notre fichier, nous allons exécuter le code avec la commande `node index.js`. Nous devrions voir le message `hello world` dans notre terminal. Cela signifie que le projet est bien configuré ! ## Lecture d'un fichier NodeJS avec _fs_ Nous pouvons maintenant charger le fichier CSV au sein de notre dossier. Il suffit de modifier notre fonction en rajoutant les instructions suivantes : ```javascript index.js const filePath = './MOCK_DATA.csv'; const fileExists = fs.readFileSync(filePath); if (!fileExists) { throw new Error(`Le fichier ${filePath} n'existe pas.`); } ``` - La première instruction spécifie le chemin relatif vers notre fichier CSV, ici `./MOCK_DATA.csv` - La seconde instruction permet d'ouvrir le fichier avec la méthode `fs.readFileSync` pour s'assurer que le fichier existe. - Si le fichier n'existe pas, nous déclenchons une erreur avec le message `Le fichier MOCK_DATA.csv n'existe pas.` Nous sauvegardons notre fichier pour l'exécuter à nouveau avec notre terminal avec la commande `node index.js`. L'erreur n'a pas été déclenchée, cela signifie que notre fichier a été lu par _fs_. Nous pouvons maintenant passer à la conversion. ## Conversion CSV en JSON avec csv-parser Nous avons besoin installer la librairie `csv-parser` pour pouvoir l'utiliser. ```bash Terminal npm i csv-parser ``` Une fois installée, nous allons importer la librairie à l'intérieur de notre fichier. Notre fichier contient maintenant ces instructions : ```javascript index.js import fs from 'fs'; import parser from 'csv-parser'; export const readCsvFile = () => { const filePath = './MOCK_DATA.csv'; const fileExists = fs.readFileSync(filePath); if (!fileExists) { throw new Error(`Le fichier ${filePath} n'existe pas.`); } }; readCsvFile(); ``` La documentation officielle de `csv-parser` nous aide avec l'instruction suivante que nous allons rajouter dans notre code : ```javascript index.js fs.createReadStream(filePath) .pipe(parser()) .on('data', (row) => results.push(row)) .on('end', () => { console.log(results); }); ``` Prenons le temps d'analyser ces lignes. - Nous appelons d'abord la méthode `fs.createReadStream` qui accepte en paramètre notre variable `filePath` (chemin relatif vers le fichier CSV). - Nous appelons ensuite la fonction chaînée `pipe` qui accepte en paramètre une destination (un flux de données, dans notre cas la méthode `parser` que nous avons précédemment importé. - Nous appelons finalement les fonctions chaînées `.on` qui prennent en premier paramètre un évènement (lire un fichier CSV déclenche plusieurs types d'évènements : `error` en cas d'erreur, `data` en cas de lecture de ligne, `end` à la fin de traitement du fichier). - Chaque évènement est suivi d'une fonction de rappel (callback). - Notre évènement `data` va ajouter chaque ligne dans un tableau d'objets nommé `results` (il ne faut pas oublier de le déclarer au dessus de l'instruction) - Notre évènement `end` qui va afficher sur notre terminal notre tableau de lignes traitées à la fin du traitement. ## Code final Nous rajoutons la commande trouvée sur la documentation de `csv-parser`, modifiée pour répondre à nos critères. ```javascript index.js import fs from 'fs'; import parser from 'csv-parser'; export const readCsvFile = () => { const filePath = './MOCK_DATA.csv'; const fileExists = fs.readFileSync(filePath); if (!fileExists) { throw new Error(`Le fichier ${filePath} n'existe pas.`); } let results = []; fs.createReadStream(filePath) .pipe(parser()) .on('data', (row) => results.push(row)) .on('end', () => { console.log(results); }); }; readCsvFile(); ``` Nous avons déclaré une nouvelle variable `results` qui va stocker chaque ligne transformée en _JSON_. Nous pouvons sauvegarder notre fichier, et l'exécuter dans notre invité de commande pour vérifier son fonctionnement ```bash Terminal node index.js ``` Le terminal affiche un tableau d'objet, correspondant à notre fichier CSV. Chaque clé de notre objet est nommée correspondant au titre (l'en-tête en première ligne) du fichier. ![Mon terminal affichant des données CSV converties en JSON](https://algomax-public.s3.eu-west-3.amazonaws.com/image_6986166208.jpg) Nous avons réussi la conversion de notre fichier CSV en JSON. J'espère que ce guide vous a été utile. Merci aux contributeurs du [projet](https://csv.js.org/) qui proposent également d'autres librairies, permettant de manipuler davantage de fichiers CSV. --- ## Pour aller plus loin Une fois que tu sais manipuler tes données, la question devient : qu'en fais-tu ? - Pour les exposer côté app mobile : [agence application mobile React Native](/services/application-mobile). - Pour automatiser un workflow complet : [agent IA WhatsApp](/services/agent-ia-whatsapp) ou [chatbot Telegram](/services/agent-ia-telegram). - Lancer un produit data-driven ? Voir [le guide SaaS pour fondateurs](/blog/creer-une-application-saas-le-guide-pratique-pour-fondateurs). --- ## Algomax : l'agence web et IA qui accompagne les entreprises ambitieuses URL: https://algomax.fr/blog/projet-algomax Publié le : 2023-02-06 Description : Algomax est une agence de développement web, mobile et IA basée à Strasbourg. Découvrez notre histoire, nos services et notre approche. # Algomax : l'agence web et IA qui accompagne les entreprises ambitieuses Algomax est née d'un constat simple. Beaucoup d'entreprises ont des idées, des processus à améliorer, des projets numériques en tête. Mais elles ne savent pas par où commencer. Ou elles ont déjà essayé, avec des résultats décevants. Nous sommes une agence de développement basée à Strasbourg. Nous concevons des applications web, des applications mobiles, des plateformes SaaS et des solutions d'intelligence artificielle. Notre métier : transformer vos idées en outils concrets qui fonctionnent. ## Ce que nous faisons ### Applications web Nous construisons des applications web sur mesure, adaptées à votre activité. Que vous ayez besoin d'un espace client, d'un tableau de bord interne, d'un outil de gestion ou d'une plateforme complète, nous développons la solution qui correspond à votre besoin réel. Pas de template générique. Chaque projet est pensé pour votre cas d'usage. [En savoir plus sur nos applications web](/services/application-web) ### Applications mobiles Vos clients et vos équipes utilisent leur téléphone en permanence. Nous développons des applications mobiles disponibles sur iPhone et Android, à partir d'une base de code unique grâce à React Native. Résultat : un développement plus rapide et des coûts maîtrisés. [Découvrir nos applications mobiles](/services/application-mobile) | [En savoir plus sur la création d'applications mobiles](/services/creation-application-mobile) ### Plateformes SaaS Vous avez une idée de produit logiciel vendu en abonnement ? Nous concevons et développons des plateformes SaaS complètes, de l'inscription des utilisateurs à la facturation, en passant par les tableaux de bord et les intégrations. [Découvrir nos plateformes SaaS](/services/application-saas) ### Agents IA et intelligence artificielle L'intelligence artificielle n'est pas réservée aux grandes entreprises. Nous créons des agents IA capables d'automatiser des tâches répétitives, de répondre à vos clients, d'analyser des documents ou de traiter des données. Ces agents s'intègrent directement dans vos outils existants. [Découvrir nos agents IA](/services/agent-ia) | [Agents IA sur mesure](/services/agent-ia-sur-mesure) ### Automatisation avec n8n Vous passez des heures à copier des données d'un outil à l'autre ? À envoyer des emails manuellement ? Nous mettons en place des automatisations avec n8n, un outil qui connecte vos applications entre elles et fait le travail à votre place. [En savoir plus sur l'automatisation n8n](/services/automatisation-n8n) ### Référencement naturel (SEO) Un site web qui n'apparaît pas dans Google, c'est un site qui n'existe pas pour vos clients potentiels. Nous travaillons le référencement naturel de vos pages pour améliorer votre visibilité. [Découvrir notre offre SEO](/services/referencement-naturel-seo) ## Notre approche Nous ne commençons jamais par la technologie. Nous commençons par comprendre votre problème. Trop de projets échouent parce qu'on a construit le mauvais outil. Un logiciel parfaitement développé mais qui ne répond pas au bon besoin, ça ne sert à rien. Nous prenons le temps de comprendre votre activité, vos processus, vos difficultés quotidiennes. Ensuite seulement, nous proposons une solution technique adaptée. Notre processus en quatre étapes : 1. **Écoute.** Nous analysons votre besoin, votre marché et vos contraintes. 2. **Proposition.** Nous vous présentons une solution claire, avec un périmètre défini, un budget et un calendrier. 3. **Développement.** Nous construisons votre projet par étapes. Vous voyez l'avancement régulièrement et pouvez donner votre retour à chaque étape. 4. **Livraison et suivi.** Nous déployons la solution, formons vos équipes si nécessaire et restons disponibles pour la maintenance et les évolutions. ## Les technologies que nous utilisons Pour les curieux, voici les outils avec lesquels nous travaillons au quotidien : - **React et Next.js** : pour construire des interfaces web rapides et modernes - **Node.js** : pour la partie serveur de vos applications - **React Native** : pour les applications mobiles iPhone et Android - **Python** : pour les projets d'intelligence artificielle et de traitement de données - **PostgreSQL** : une base de données fiable et performante - **Docker** : pour déployer vos applications de manière stable et reproductible - **n8n** : pour automatiser vos processus métier Le choix de la technologie dépend toujours du projet. Nous choisissons ce qui convient le mieux à votre situation. ## Avec qui nous travaillons Nos clients sont des PME, des startups et des ETI qui veulent : - Créer un produit numérique (application, plateforme, outil interne) - Automatiser des tâches répétitives pour gagner du temps - Intégrer l'intelligence artificielle dans leurs processus - Améliorer leur présence en ligne et leur référencement Nous travaillons avec des entreprises de toutes tailles. Ce qui compte pour nous, c'est la clarté du projet et la volonté d'avancer. ## Pourquoi Algomax Nous sommes une petite équipe. C'est un choix. Cela signifie que vous ne parlez pas à un commercial qui transmet votre demande à un chef de projet qui la transmet à un développeur. Vous parlez directement aux personnes qui construisent votre projet. Cette proximité nous permet d'être réactifs, de comprendre vos retours rapidement et d'ajuster le cap sans perdre des semaines en réunions. Nous croyons aussi à la transparence. Pas de coûts cachés, pas de fonctionnalités ajoutées sans votre accord, pas de surprises à la livraison. ## Envie d'en discuter ? Vous avez un projet en tête ? Une idée que vous aimeriez explorer ? Un processus qui vous prend trop de temps ? [Contactez-nous](/contact). Nous prendrons le temps de comprendre votre besoin et de vous dire honnêtement si nous pouvons vous aider. --- ## Terminal personnalisé: gagner du temps au quotidien URL: https://algomax.fr/blog/optimisez-du-temps-avec-un-terminal-personnalise Publié le : 2022-10-07 Description : Optimisez votre terminal de dev avec une configuration lisible et rapide pour accélérer vos workflows. > Mise à jour SEO (Mars 2026) > > Cette version met l’accent sur des réglages concrets qui améliorent la vitesse d’exécution et la lisibilité de vos sessions terminal. ## Comment configurer un thème zsh de terminal ? Le temps est une ressource **précieuse**. En tant que développeur, je souhaite être efficace et développer de belles *features* rapidement. J'utilise très souvent mon terminal pour lancer les commandes `git`, mettre à jour mes projets, changer le `php.ini` ... Ces commandes sont très **monotones** et **répétitives**. Je vais vous montrer aujourd'hui comment gagner un peu de temps grâce au thème de terminal **ZSH**. ![Invité de commande (terminal) personnalisé proposant auto-completion, correction de syntaxe][Link](link)(https://algomax-public.s3.eu-west-3.amazonaws.com/starship_terminal_696fc275c1.gif) ## Installer sur Ubuntu ### 1. Installation de ZSH, mise à jour du système ```bash Terminal sudo apt-get install zsh powerline fonts-powerline git -y sudo apt-get update && sudo apt full-upgrade -y ``` ### 2. Installation de Starship ```bash Terminal curl -sS https://starship.rs/install.sh | sh ``` ### 3. Installation de Oh My Zsh. Il faudra fermer et rouvrir le terminal pour que les modifications soient prises en compte. ```bash Terminal sh -c "$(curl -fsSL https://raw.github.com/ohmyzsh/ohmyzsh/master/tools/install.sh)" ``` ### 4. Installation des plugins ZSH ```bash Terminal git clone https://github.com/zsh-users/zsh-autosuggestions ${ZSH_CUSTOM:-~/.oh-my-zsh/custom}/plugins/zsh-autosuggestions git clone https://github.com/zsh-users/zsh-completions ${ZSH_CUSTOM:=~/.oh-my-zsh/custom}/plugins/zsh-completions git clone https://github.com/zsh-users/zsh-syntax-highlighting ${ZSH_CUSTOM:=~/.oh-my-zsh/custom}/plugins/zsh-syntax-highlighting ``` ### 5. Configuration de Starship et des plugins ZSH ```bash Terminal sudo nano ~/.zshrc ``` On va modifier le fichier `~/.zshrc` généré par [Oh My Zsh](https://ohmyz.sh/) et remplacer son contenu par : ```bash Terminal export ZSH="$HOME/.oh-my-zsh" plugins=( git zsh-autosuggestions zsh-completions zsh-syntax-highlighting ) source $ZSH/oh-my-zsh.sh eval "$(starship init zsh)" ``` ### 6. Redémarrer le terminal ```bash Terminal source ~/.zshrc ``` ### 7. Décollage 🚀 Vous êtes maintenant parés à utiliser ce terminal **efficace** et **optimisé** ! **N.B** : Vous développez des applications **Javascript** ? N'oubliez pas de réinstaller `npm` ou `nvm` ! Vous pouvez retrouver la documentation officielle de `nvm` [ici](https://github.com/nvm-sh/nvm#install--update-script). ## Installer sur Mac ### 1. Installation de [Brew](https://brew.sh/), le package manager macOS ```bash Terminal /bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)" ``` ### 2. Installation de [ZSH](https://formulae.brew.sh/formula/zsh) ```bash Terminal brew install zsh ``` ### 3. Installation, de Oh My Zsh ```bash Terminal sh -c "$(curl -fsSL https://raw.github.com/ohmyzsh/ohmyzsh/master/tools/install.sh)" ``` ### 4. Installation de Starship ```bash Terminal curl -sS https://starship.rs/install.sh | sh ``` ### 5. Installation des plugins ZSH ```bash Terminal git clone https://github.com/zsh-users/zsh-autosuggestions ${ZSH_CUSTOM:-~/.oh-my-zsh/custom}/plugins/zsh-autosuggestions git clone https://github.com/zsh-users/zsh-completions ${ZSH_CUSTOM:=~/.oh-my-zsh/custom}/plugins/zsh-completions git clone https://github.com/zsh-users/zsh-syntax-highlighting ${ZSH_CUSTOM:=~/.oh-my-zsh/custom}/plugins/zsh-syntax-highlighting ``` ### 6. Configuration de Starship et des plugins ZSH ```bash Terminal sudo nano ~/.zshrc ``` On va modifier le fichier `~/.zshrc` généré par [Oh My Zsh](https://ohmyz.sh/) et remplacer son contenu par : ```bash Terminal export ZSH="$HOME/.oh-my-zsh" plugins=( git zsh-autosuggestions zsh-completions zsh-syntax-highlighting ) source $ZSH/oh-my-zsh.sh eval "$(starship init zsh)" ``` ### 7. Redémarrer le terminal ```bash Terminal source ~/.zshrc ``` ### 8. Décollage 🚀 Vous êtes maintenant parés à utiliser ce terminal **efficace** et **optimisé** ! **N.B** : Vous développez des applications **Javascript** ? N'oubliez pas de réinstaller `npm` ou `nvm` ! Vous pouvez retrouver la documentation officielle de `nvm` [ici](https://github.com/nvm-sh/nvm#install--update-script). ## Guide de l'installation sur Ubuntu avec explications ### 1. Télécharger Powerline En premier lieu, nous avons besoin d'installer une police spéciale qui va nous permettre de voir des **icônes** et des **indicateurs** dans le terminal. Commencez par ouvrir votre terminal et entrez la commande suivante. ```bash Terminal sudo apt-get install zsh powerline fonts-powerline git curl -y ``` - [`zsh`](https://doc.ubuntu-fr.org/zsh) est l'interpréteur de commandes (**shell**) que nous allons utiliser - [`powerline`](https://github.com/powerline/powerline) est un plugin pour notre terminal. C'est lui qui affiche les icônes de la branche active dans Git, de la version de PHP, etc - [`fonts-powerline`](https://github.com/powerline/fonts) est un repository possédant une trentaine de polices de terminal (avec icônes) - [`git`](https://git-scm.com/) est un outil de versionning que nous allons utiliser pour installer le thème - [`curl`](https://curl.se/) est un outil qui nous permet de télécharger des fichiers depuis le web - [`-y`](https://askubuntu.com/a/672893) est un paramètre qui demande à Ubuntu de ne pas nous embêter à confirmer l'installation des paquets. ### 2. Mettre à jour les paquets Nous allons mettre à jour les paquets pour installer leur dernière version. Pour cela, entrez la commande suivante. ```bash Terminal sudo apt-get update && sudo apt full-upgrade -y ``` ### 3. Installer Oh My zsh [Oh My Zsh](https://ohmyz.sh/) est un framework qui va nous aider à configurer notre terminal. Il nous propose plus de **275** plugins et de nombreux thèmes. Pour l'installer, il suffit de lancer la [commande suivante](https://ohmyz.sh/#install) dans le terminal. ```bash Terminal sh -c "$(curl -fsSL https://raw.github.com/ohmyzsh/ohmyzsh/master/tools/install.sh)" ``` Après l'installation, **ZSH** nous demande si on accepte d'en faire notre terminal par défaut. Après avoir répondu, il nous affiche un beau message de confirmation d'installation. Essayez de fermer votre terminel et de le rouvrir, vous verrez qu'il a bien changé 😄 . ![Invité de commande (terminal) affichant un message de succès de l'installation de Oh My Zsh](https://algomax-public.s3.eu-west-3.amazonaws.com/ohmyzsh_successful_install_ce06ca98a4.jpg) ### 4. Comprendre le fichier de configuration Passons maintenant à un peu de configuration ! Notre terminal est beau, mais il n'est pas plus pratique pour autant. Nous allons maintenant modifier le fichier de configuration `~/.zshrc`, qui se trouve à la racine de votre dossier utilisateur. Pour l'ouvrir, il suffit de lancer la commande suivante. Je vous conseille d'utiliser `sudo` pour être sûr de pouvoir le sauvegarder. ```bash Terminal sudo nano ~/.zshrc ``` On se retrouve avec un fichier contenant beaucoup de lignes ! **ZSH** est très configurable, et nous avons beaucoup de lignes commentées en bleu, préfixées par `#`. Ce sont des exemples de syntaxes à titre indicatif pour nous indiquer les possibilités de configuration. Personnellement, je trouve que c'est illisible. J'ai supprimé tous les commentaires pour ne conserver que l'essentiel. ![Configuration du fichier zshrc. Beaucoup de lignes s'y retrouvent et il est simple de s'y perdre](https://algomax-public.s3.eu-west-3.amazonaws.com/zshrc_configuration_63f1d5a8f9.jpg) Voici les lignes qui restent après nettoyage : ```bash Terminal export ZSH="$HOME/.oh-my-zsh" ZSH_THEME="robbyrussell" plugins=(git) source $ZSH/oh-my-zsh.sh ``` - La première ligne permet d'exporter une variable d'environnement, contenant le chemin vers la configuration de **ZSH**. - La deuxième ligne permet de configurer le thème. Cependant ce n'est pas le thème robbyrussell qui est actif actuellement. - La troisième ligne permet de configurer une liste de plugins. C'est la partie qui nous intéresse car nous allons en rajouter trois. - La dernière ligne permet de charger la configuration de **ZSH**. On sauvegarde la modification d'un fichier édité avec `nano` avec les touches `Ctrl + X`. L'éditeur nous demande si l'on souhaite sauvegarder, et nous répondons par Oui `Y` ou Non `N`, puis `Entrée`. On peut également annuler une modification avec `Ctrl + C`. Maintenant, nous allons installer le thème `starship` ainsi que quelques plugins et nous pourrons profiter d'un terminal très efficace ! ### 5. Installer le thème starship [Starship](https://starship.rs/) est un thème pour **ZSH** qui propose une **barre de statut** avec des informations sur la branche Git, la version de PHP et plein de trucs sympa ! Nous allons donc l'installer avec la commande suivante. ```bash Terminal curl -sS https://starship.rs/install.sh | sh ``` **Starship** nous demande de valider l'installation avec `Y` ou `N`. Après avoir répondu, il nous affiche un beau message de confirmation d'installation. Nous allons maintenant configurer notre terminal pour qu'il utilise ce thème. ```bash Terminal sudo nano ~/.zshrc ``` Nous rajoutons la ligne `eval "$(starship init zsh)"` à la fin du fichier `~/.zshrc`. Regardons à quoi il ressemble : ```bash Terminal export ZSH="$HOME/.oh-my-zsh" ZSH_THEME="robbyrussell" plugins=(git) source $ZSH/oh-my-zsh.sh eval "$(starship init zsh)" ``` ### 6. Installer les plugins d'autocomplétion et de correction Passons donc à la pratique en installant les plugins suivants : #### zsh-autosuggestions Ce [plugin](https://github.com/zsh-users/zsh-autosuggestions) nous affiche des suggestions de commande en fonction de ce que nous avons déjà tapé. C'est très pratique pour éviter de retaper des commandes déjà saisies. Il suffit d'avoir une suggestion de d'appuyer sur → (flèche de droite) pour saisir la commande. La commande suivante permet de l'installer au sein du dossier plugins de notre configuration `oh-my-zsh`. ```bash Terminal git clone https://github.com/zsh-users/zsh-autosuggestions ${ZSH_CUSTOM:-~/.oh-my-zsh/custom}/plugins/zsh-autosuggestions ``` #### zsh-completions Je n'ai pas réussi à comprendre le but de ce [plugin](https://github.com/zsh-users/zsh-completions), que je télécharge pourtant à chaque fois que je configure un nouveau terminal. Il permet d'ajouter des complétions de commandes supplémentaires. ```bash Terminal git clone https://github.com/zsh-users/zsh-completions ${ZSH_CUSTOM:=~/.oh-my-zsh/custom}/plugins/zsh-completions ``` #### zsh-syntax-highlighting Ce [plugin](https://github.com/zsh-users/zsh-syntax-highlighting) permet de colorer nos commandes en fonction de leur syntaxe. Si tu entres une commande erronée, elle sera colorée en rouge. Cela te permet de ne pas l'exécuter et de la corriger avant de la lancer. ![Exemple de coloration de commande en rouge pour une commande erronée, en vert pour une commande valide](https://algomax-public.s3.eu-west-3.amazonaws.com/zsh_syntax_highlighting_7711c8cb0f.jpg) Installons ce dernier plugin et nous serons enfin prêts. ```bash Terminal git clone https://github.com/zsh-users/zsh-syntax-highlighting ${ZSH_CUSTOM:=~/.oh-my-zsh/custom}/plugins/zsh-syntax-highlighting ``` #### Modifier la configuration Maintenant, nous allons ouvrir à nouveau notre fichier de configuration `~/.zshrc` pour lui demander d'exécuter chacun de nos plugins quand il se lance. ```bash Terminal sudo nano ~/.zshrc ``` Et nous y collons le nom des trois nouveaux plugins. ```bash Terminal export ZSH="$HOME/.oh-my-zsh" ZSH_THEME="robbyrussell" plugins=( git zsh-autosuggestions zsh-completions zsh-syntax-highlighting ) source $ZSH/oh-my-zsh.sh eval "$(starship init zsh)" ``` Il suffit à présent de redémarrer le terminal pour que les modifications soient prises en compte. ```bash Terminal source ~/.zshrc ``` ### Conclusion Nous venons de configurer un terminal **surpuissant**. Bonne chance pour vos développements ! ## Aller plus loin avec Algomax - [Développement d'agent IA sur mesure](/services/agent-ia) - [Création d'application SaaS](/services/application-saas) - [Développement d'application mobile](/services/application-mobile) - [Agence IA à Strasbourg](/agence-strasbourg) --- # Pages services et comparatifs - https://algomax.fr/services/agent-ia - https://algomax.fr/services/chatbot-ia - https://algomax.fr/services/prix-agent-ia - https://algomax.fr/services/agent-ia-sur-mesure - https://algomax.fr/services/agent-ia-service-client - https://algomax.fr/services/agent-ia-email - https://algomax.fr/services/agent-ia-vocal - https://algomax.fr/services/automatisation-n8n - https://algomax.fr/services/agent-ia-whatsapp - https://algomax.fr/services/agent-ia-telegram - https://algomax.fr/services/agent-ia-recrutement - https://algomax.fr/services/agent-ia-comptabilite - https://algomax.fr/services/agent-ia-immobilier - https://algomax.fr/services/agent-ia-juridique - https://algomax.fr/services/agent-ia-e-commerce - https://algomax.fr/services/ia-generative - https://algomax.fr/services/application-saas - https://algomax.fr/services/application-saas-ia - https://algomax.fr/services/application-mobile - https://algomax.fr/services/application-mobile-ia - https://algomax.fr/services/site-web - https://algomax.fr/services/nextjs-migration - https://algomax.fr/services/react-router-development - https://algomax.fr/services/tailwind-css-experts - https://algomax.fr/services/vibe-coding-cleanup - https://algomax.fr/services/cto-freelance - https://algomax.fr/services/developpement-fullstack - https://algomax.fr/services/audit-technique - https://algomax.fr/agent-ia-vs-chatbot - https://algomax.fr/react-native-vs-flutter - https://algomax.fr/n8n-vs-zapier - https://algomax.fr/lovable-vs-developpeur - https://algomax.fr/prix-site-web - https://algomax.fr/prix-application-web - https://algomax.fr/prix-agent-ia - https://algomax.fr/prix-application-mobile