Quand les hooks, les appels d’API, les mutations d’état et le rendu JSX cohabitent dans un même fichier, tu perds le contrôle. Le code devient impossible à tester, à maintenir, à faire évoluer. Tu veux éviter ça ? Lis ce qui suit.
Votre stack vous ralentit ?
Je vous propose un audit technique gratuit pour identifier les freins à la performance ou à la maintenabilité.
Tu veux scaler un projet React Native ? Alors sépare. Si tu ne peux pas expliquer en 5 secondes où est la logique métier d’un écran, c’est que tu as échoué à architecturer ton app.
Découvrez comment utiliser l’architecture hexagonale avec ReactJS
Dans un monde où la souveraineté numérique, la résilience et la scalabilité sont devenues des enjeux stratégiques, de plus en plus d’entreprises se tournent vers une stratégie multi-cloud. Objectif : éviter la dépendance à un seul fournisseur (vendor lock-in), optimiser les performances et garantir la disponibilité des services critiques. Mais très vite, un piège se referme : l’explosion des coûts, la complexité d’orchestration, la duplication des ressources…
« Chaque équipe utilisait son cloud préféré. Rien n’était compatible. Le jour où on a voulu migrer un service de staging vers la prod, tout a cassé. »
Beaucoup d’équipes commencent en mono-cloud, avec les outils maison du provider. Ça fonctionne… jusqu’au jour où on veut :
changer de cloud pour une question de coût ou souveraineté,
déployer dans un autre pays,
ou isoler des services sensibles.
Si ton stack est verrouillé sur un provider, t’es piégé.
💡 Solution : standardiser ton socle technique pour qu’il soit portable :
Conteneurisation (Docker, Podman) → packager tout de la même façon.
Orchestrateur commun (Kubernetes, Nomad) → une seule logique de déploiement.
Infrastructure as Code (Terraform, Pulumi) → tout est versionné, réutilisable.
Résultat ? Tu peux répliquer un environnement complet sur un autre cloud en quelques heures. Sans tout réécrire.
🧰 Étape 2 — Choisir ses clouds avec une logique de mission
« Pourquoi notre frontend est sur Azure, le backend sur AWS et la base chez OVH ? — Personne ne savait. »
Le multi-cloud n’a de sens que si chaque service est à sa place :
stockage froid sur un provider éco,
IA sur un cloud hyper spécialisé,
data sensible sur un hébergeur souverain ou auto-hébergé.
C’est pas une question de techno. C’est une décision de bon sens, motivée par :
la sécurité,
les coûts,
la conformité.
Et comme on dit toujours, pas tous les oeufs dans le même panier.
💡 Étape 3 — Penser FinOps dès le début
« On pensait que le staging coûtait 100€/mois. La facture : 480. Une base oubliée, deux volumes jamais supprimés, et des instances qui tournaient la nuit. »
Dans le multi-cloud, les coûts s’éparpillent. Tu ne les vois pas venir. Penser FinOps, ce n’est pas juste installer un outil de suivi. C’est :
estimer les coûts avant chaque déploiement,
automatiser l’extinction des environnements non critiques,
éviter la duplication inutile (ex: pas 3 bases SQL pour 3 microservices).
En intégrant ces réflexes tôt, tu évites les mauvaises surprises. Et surtout, tu gardes la main. Pas de factures en souffrance.
🔐 Étape 4 — Sécurité : c’est toi le garant
« Notre stockage objet était public. Par défaut. Et personne ne l’avait vu. »
Chaque cloud a sa façon de gérer les accès, les secrets, les logs… Et ça rend le multi-cloud dangereux si tu ne centralises pas ta sécurité.
Une stack multi-cloud doit avoir :
un point unique de gestion des secrets,
des identités gérées via un SSO ou OIDC,
une politique claire de journalisation et d’audit.
Tu ne peux pas tout vérifier à la main. Tu dois t’outiller, documenter, automatiser.
La souveraineté, ce n’est pas juste choisir un cloud français. C’est assumer la responsabilité de tes données, partout.
📡 Étape 5 — Supervision et contrôle : savoir, pas espérer
« Un jour, un cluster K3s est tombé. Personne n’a été alerté. Les logs n’étaient pas centralisés. On a passé 2h à chercher ce qui se passait. »
Dans un système distribué, c’est ta visibilité qui fait ta résilience. S’il te manque un dashboard, un log, un backup, tu es aveugle. Et vulnérable.
C’est pourquoi dès le départ, il faut :
superviser tous les clusters et clouds dans un seul outil (Grafana, Datadog, etc.),
agréger les logs et les erreurs dans un endroit unique,
automatiser les backups entre les clouds, et tester leur restauration.
Pas besoin d’un gros budget. Juste d’une stratégie claire. Et d’une règle simple : aucune brique ne doit être orpheline.
Envie d’un audit gratuit de votre stack actuelle ou de discuter stratégie multi-cloud ?
L’architecture hexagonale, également connue sous le nom de « Ports et Adaptateurs », est une approche de conception logicielle qui vise à créer des applications flexibles, maintenables et testables. Elle sépare clairement les préoccupations entre le domaine métier, l’infrastructure et l’interface utilisateur.
Dans ce tutoriel, nous allons explorer comment structurer une application React avec Redux en utilisant une architecture hexagonale. Nous prendrons l’exemple d’une gestion d’utilisateurs pour illustrer les concepts, en suivant la structure de projet détaillée ci-dessous.
Votre stack vous ralentit ?
Je vous propose un audit technique gratuit pour identifier les freins à la performance ou à la maintenabilité.
import React from 'react';
import { Link, Outlet } from 'react-router-dom';
const DashboardLayout: React.FC = () => {
return (
<div className="dashboard-layout">
<nav>
<ul>
<li><Link to="/users">Utilisateurs</Link></li>
{/* Autres liens de navigation */}
</ul>
</nav>
<main>
<Outlet />
</main>
</div>
);
};
export default DashboardLayout;
5. Point d’entrée principal
app/App.tsx
import React from 'react';
import { BrowserRouter as Router, Routes, Route } from 'react-router-dom';
import DashboardLayout from './layout/Dashboard';
import FullPageLayout from './layout/FullPage';
import UserRoutes from './routes/userRoutes';
const App: React.FC = () => {
return (
<Router>
<Routes>
<Route path="/" element={<DashboardLayout />}>
{/* Routes principales */}
<Route path="users/*" element={<UserRoutes />} />
</Route>
{/* Routes avec un autre layout */}
<Route path="/login" element={<FullPageLayout>{/* Composant de connexion */}</FullPageLayout>} />
</Routes>
</Router>
);
};
export default App;
Styles (styles/)
Le dossier styles/ contient vos fichiers CSS ou SCSS pour styliser votre application.
Utils (utils/)
Le dossier utils/ contient des fonctions utilitaires réutilisables dans votre application.
Conclusion
En adoptant une architecture hexagonale dans votre application React avec Redux, vous bénéficiez d’une séparation claire des responsabilités :
Domaine : Contient la logique métier pure et est indépendant des frameworks et bibliothèques.
Infrastructure : Gère les détails techniques comme les appels API et le stockage.
Application : Gère l’interface utilisateur et l’état de l’application.
En modifiant les thunks pour qu’ils utilisent les services du domaine plutôt que d’accéder directement à l’infrastructure, vous respectez pleinement les principes de l’architecture hexagonale. Cela permet de garder votre couche d’application indépendante des détails techniques de l’infrastructure.
Cette architecture facilite la maintenance, les tests et l’évolutivité de votre application.
JavaScript, often misunderstood and sometimes underestimated, is a cornerstone of modern web development. Despite its ubiquitous presence and essential role in the tech landscape, many developers and tech enthusiasts only scratch the surface of its rich history and intricate construction. In this blog post, we will demystify JavaScript by exploring its origins, evolution, and core characteristics.
JavaScript was created in 1995 by Brendan Eich while he was working at Netscape Communications. Initially developed in just ten days, JavaScript was designed to enable web pages to become interactive. Originally called Mocha, then LiveScript, it was finally named JavaScript to capitalize on the popularity of Java, despite having little in common with it. This rapid development and rebranding laid the foundation for what would become a pivotal technology in the web’s evolution.
Early challenges and standardization
In its early days, JavaScript faced significant challenges, including inconsistent browser support and performance issues. These hurdles led to the formation of the ECMA International committee in 1997, which standardized JavaScript as ECMAScript. The standardization efforts aimed to ensure consistent behavior across different web browsers, leading to the first official release, ECMAScript 1, in 1997. This move was crucial for the language’s stability and widespread adoption.
JavaScript is known for its versatility and unique features. It supports multiple programming paradigms, including imperative, functional, and event-driven programming. One of its standout features is its asynchronous nature, which allows developers to handle events and perform tasks without blocking the main thread. This is particularly important for creating responsive and efficient web applications. Additionally, JavaScript’s prototype-based inheritance and first-class functions contribute to its flexibility and power.
Despite its strengths, JavaScript has faced criticism and misconceptions over the years. Early versions of the language were often dismissed as « toy » languages due to their perceived simplicity and performance limitations. However, modern advancements, such as Just-In-Time (JIT) compilation and the introduction of powerful frameworks and libraries, have significantly enhanced JavaScript’s capabilities. Today, it’s a robust and mature language that powers complex applications and systems.
JavaScript’s evolution is ongoing, with new features and improvements being added regularly. The ECMAScript standards body continues to refine and expand the language, with recent updates introducing features like async/await, modules, and optional chaining. These enhancements not only make JavaScript more powerful but also more accessible and enjoyable for developers. The language’s continuous evolution ensures that it remains at the forefront of web development.
JavaScript’s journey from a hastily developed scripting language to a cornerstone of web development is a testament to its resilience and adaptability. By understanding its history, key features, and ongoing evolution, we can better appreciate its pivotal role in the tech world. JavaScript is more than just a language; it’s a driving force behind the interactive, dynamic experiences that define the modern web.
Pour offrir les meilleures expériences, nous utilisons des technologies telles que les cookies pour stocker et/ou accéder aux informations des appareils. Le fait de consentir à ces technologies nous permettra de traiter des données telles que le comportement de navigation ou les ID uniques sur ce site. Le fait de ne pas consentir ou de retirer son consentement peut avoir un effet négatif sur certaines caractéristiques et fonctions.
Fonctionnel
Toujours activé
L’accès ou le stockage technique est strictement nécessaire dans la finalité d’intérêt légitime de permettre l’utilisation d’un service spécifique explicitement demandé par l’abonné ou l’utilisateur, ou dans le seul but d’effectuer la transmission d’une communication sur un réseau de communications électroniques.
Préférences
L’accès ou le stockage technique est nécessaire dans la finalité d’intérêt légitime de stocker des préférences qui ne sont pas demandées par l’abonné ou l’internaute.
Statistiques
Le stockage ou l’accès technique qui est utilisé exclusivement à des fins statistiques.Le stockage ou l’accès technique qui est utilisé exclusivement dans des finalités statistiques anonymes. En l’absence d’une assignation à comparaître, d’une conformité volontaire de la part de votre fournisseur d’accès à internet ou d’enregistrements supplémentaires provenant d’une tierce partie, les informations stockées ou extraites à cette seule fin ne peuvent généralement pas être utilisées pour vous identifier.
Marketing
L’accès ou le stockage technique est nécessaire pour créer des profils d’internautes afin d’envoyer des publicités, ou pour suivre l’utilisateur sur un site web ou sur plusieurs sites web ayant des finalités marketing similaires.