J'ai Testé Gemini 3.1 Flashlight — La Bête de Vitesse de Google
Trois cent soixante-trois tokens par seconde.
J'ai lu ce chiffre sur la fiche technique et j'ai cru à une coquille. Je travaille avec des modèles d'IA depuis assez longtemps pour savoir que les revendications de vitesse viennent presque toujours avec des astérisques, des petits caractères et des conditions de benchmark que personne ne rencontre réellement dans l'utilisation quotidienne. Alors quand Google a lancé Gemini 3.1 Flashlight — positionné comme leur modèle le plus rapide et le plus efficient en coûts à ce jour — j'ai fait ce que tout développeur sceptique ferait. J'ai ouvert mon terminal, accédé à l'API et j'ai commencé à lui envoyer des tâches réelles.
Ce qui s'est passé pendant les heures suivantes m'a véritablement surpris. Pas parce que le modèle est parfait — il ne l'est absolument pas — mais parce qu'il a fondamentalement changé ma façon de penser à quel modèle appartient à quelle partie de mon stack de développement. Il existe une classe spécifique de travail où Flashlight ne fait pas que concurrencer les modèles plus grands. Il les humilie.
Mais je m'avance. Avant de vous dire ce qui m'a époustouflé (et ce qui a déçu), vous devez comprendre ce que Google essayait réellement de construire — et pourquoi c'est important si vous écrivez du code pour gagner votre vie.
Pourquoi un Autre Modèle "Light" Compte Vraiment Cette Fois
Voici quelque chose que j'ai remarqué sur le paysage des modèles d'IA au cours de la dernière année : l'écart entre les modèles "flagship" et "efficients" continue de se réduire de manières étranges et imprévisibles. Nous avions l'habitude de penser aux modèles plus petits comme clairement inférieurs — utiles pour des tâches rapides de classification ou du remplissage de chatbot, mais rien à qui vous confieriez du vrai travail d'ingénierie.
Cette hypothèse s'effondre. Rapidement.
Gemini 3.1 Flashlight se situe dans une catégorie que Google appelle leur tier optimisé pour la vitesse au sein de la famille Gemini 3. Le pitch est simple : prendre les gains d'intelligence de Gemini 3, éliminer l'overhead qui rend les grands modèles chers et lents, et livrer quelque chose que les développeurs peuvent réellement se permettre de faire tourner à l'échelle — sans avoir l'impression d'avoir rétrogradé.
Les tarifs racontent une partie de l'histoire : 25$ par million de tokens d'entrée, avec des tokens de sortie allant de 0,50$ à 1,50$ par million selon votre configuration. C'est agressif. Pas « tier gratuit pour projet hobby » bon marché, mais bien dans la fourchette pour des charges de travail de production où vous faites des milliers d'appels API quotidiennement.
Ce qui est plus intéressant, ce sont les données de performance. Sur le benchmark GPQA — qui teste le raisonnement de niveau doctoral — Flashlight a obtenu 86,9%. Le benchmark MMU Pro, qui évalue la compréhension multimodale, est arrivé à 76,8%. Et sur le leaderboard Arena, il a affiché un score ELO de 1400. Ce ne sont pas des chiffres de « modèle light ». Ce sont des chiffres qui auraient été de tier flagship il y a dix-huit mois.
Je construis des outils alimentés par l'IA depuis assez longtemps pour savoir que les benchmarks ne racontent que la moitié de l'histoire. L'autre moitié réside dans ce qui se passe quand vous mettez réellement le modèle au travail. C'est là que les choses sont devenues vraiment intéressantes.
Le Test de Vitesse qui a Changé Mon Avis
Mon premier vrai test était simple mais révélateur. J'ai demandé à Flashlight de générer un composant de visualiseur de produit à 360 degrés — le genre de chose que vous verriez sur un site e-commerce haut de gamme. Multiples angles de caméra, rotation fluide et capacité de changement de couleur. Pas trivial, mais pas sorcier non plus.
La réponse est revenue en secondes. Pas des secondes « assez rapide ». Le genre de vitesse où vous vous demandez si le modèle a réellement traité votre requête ou simplement mis en cache un template.
Il n'avait rien mis en cache. Le code était spécifique à mon prompt, correctement structuré et — voici la partie qui m'a pris au dépourvu — visuellement plus convaincant que ce que j'avais obtenu de Gemini 3.1 Pro pour une tâche similaire. Un modèle plus léger et moins cher produisant un meilleur output front-end que son grand frère. Ce n'est pas censé arriver.
J'ai lancé le composant dans mon navigateur. Rotation fluide. Angles de caméra fonctionnels. Le changement de couleur nécessitait un petit correctif, mais la base était solide. Pour du prototypage rapide, c'était exactement le type d'output qui m'économise une heure de scaffolding.
Maintenant, avant que vous pensiez que je vais vous dire que Flashlight est parfait pour tout — il ne l'est pas. Quand j'ai augmenté la complexité, des fissures ont commencé à apparaître. Un dashboard multi-composants avec des widgets interdépendants ? Il est arrivé à environ 70%. Quelques lacunes dans le suivi d'instructions sont apparues là où le modèle semblait perdre le fil des contraintes que j'avais définies dans le prompt.
Mais voici ce qui me revient sans cesse : le coût de cet output imparfait était négligeable. Quand vous itérez rapidement, une solution à 70% à 1/10e du prix et 3x la vitesse est souvent plus précieuse qu'une solution à 95% qui prend plus de temps et coûte plus cher à générer. Vous corrigez les lacunes plus vite que vous n'attendez le modèle cher.
Ce compromis n'est pas toujours le bon. Mais pour les workflows que j'utilise quotidiennement — prototypage rapide, génération de composants, exploration UI — c'est un game-changer à ce prix.
La Fonctionnalité « Niveau de Réflexion » dont Personne Ne Parle
Voici quelque chose que la plupart des avis sur Flashlight passent sous silence, et honnêtement, je pense que c'est la fonctionnalité la plus importante de tout le modèle.
Gemini 3.1 Flashlight inclut un paramètre ajustable de « niveau de réflexion ». Vous pouvez régler la profondeur de raisonnement à la hausse ou à la baisse selon votre tâche. Réponse de chat simple ? Baissez-le. Génération de code complexe en plusieurs étapes ? Montez-le au maximum.
Pourquoi est-ce important ? Parce que cela signifie que vous ne payez pas pour du raisonnement dont vous n'avez pas besoin.
Chaque développeur IA a vécu cette expérience : vous envoyez une simple demande de formatage à un modèle puissant, il « réfléchit » trop longtemps, brûle des tokens et livre une réponse bien plus élaborée que nécessaire. Le contrôle du niveau de réflexion élimine ce gaspillage.
J'ai testé cela sur trois scénarios :
Niveau de réflexion bas — reformater des données JSON et générer des définitions de types basiques. Les temps de réponse ont chuté dramatiquement, les coûts étaient minimaux et la qualité était exactement ce dont j'avais besoin. Pas de surréflexion.
Niveau de réflexion moyen — générer des composants React avec des exigences spécifiques de style et de gestion d'état. Bon équilibre entre vitesse et précision. C'est devenu mon paramètre par défaut pour la plupart des tâches de développement.
Niveau de réflexion haut — génération de code multi-fichiers avec logique métier complexe et gestion d'erreurs. Plus lent, mais la qualité de l'output a visiblement augmenté. Le modèle a détecté des cas limites qu'il avait manqués aux paramètres inférieurs.
La capacité d'ajuster cela dynamiquement par requête est véritablement puissante pour les systèmes de production. Imaginez router les requêtes simples d'utilisateurs vers le mode basse réflexion et les demandes analytiques complexes vers le mode haute réflexion — le tout depuis le même modèle, avec le même endpoint API. Votre infrastructure reste simple, vos coûts restent optimisés et vos utilisateurs obtiennent une qualité de réponse appropriée à leurs besoins spécifiques.
Je ne vois pas assez de développeurs parler de ce pattern, mais il va devenir une pratique standard. Notez mes mots.
Tâches Réelles, Résultats Réels : Le Détail Complet
Parler, c'est facile. Les benchmarks sont intéressants. Mais ce qui compte, c'est si le modèle fait du travail utile. J'ai passé une journée entière à lancer des tâches de difficulté croissante à Flashlight, et voici ce que j'ai trouvé.
Développement Front-End : Étonnamment Fort
C'est là que Flashlight brille véritablement — et je veux être précis sur ce que j'entends par là.
Pour la génération de composants individuels (cartes, modales, barres de navigation, présentoirs de produits, widgets interactifs), Flashlight produit un output qui est au niveau ou occasionnellement meilleur que des modèles coûtant 5 à 10 fois plus. Le code est propre, le CSS est moderne et les composants fonctionnent réellement quand vous les intégrez dans un projet.
J'ai généré une page complète de présentation de produits avec des transitions animées, des breakpoints responsifs et un balisage accessible. Le modèle a réussi le comportement responsive du premier coup. Les animations nécessitaient des ajustements — il a choisi une transition spring là où je voulais un ease linéaire — mais la structure était solide.
Là où il peine : les mises en page multi-pages avec une logique de routage complexe, les patterns de gestion d'état profondément imbriqués et les tâches où le prompt inclut plus de 6-7 exigences distinctes. Le modèle commence à lâcher des contraintes à ce niveau de complexité.
Mon verdict : Si vous faites du prototypage front-end, du développement de bibliothèques de composants ou de l'exploration UI, Flashlight devrait être votre modèle par défaut. Passez à quelque chose de plus puissant seulement quand vous en avez réellement besoin.
Génération de Code Au-delà du Navigateur
Génération de SVG ? Excellent. J'ai demandé un papillon avec des animations de battement d'ailes, et l'output était véritablement impressionnant — des paths SVG appropriés, des animations CSS keyframe fluides et des dégradés de couleurs appropriés. Le tout s'est rendu magnifiquement.
Fonctions utilitaires générales, scaffolding d'endpoints API, pipelines de transformation de données — tout solide. Flashlight écrit du code compétent et lisible pour les tâches de programmation quotidiennes.
Là où j'ai remarqué le plafond : l'implémentation d'algorithmes complexes. Quand j'ai demandé un algorithme optimisé de parcours de graphe avec des contraintes mémoire spécifiques, la première tentative était correcte mais naïve. Un modèle plus puissant aurait atteint la solution optimale immédiatement.
Génération de Jeux et Simulations : La Carte Surprise
C'est là que les choses sont devenues amusantes — et où mes attentes avaient le plus besoin de calibration.
J'ai demandé à Flashlight de construire un jeu de course 2D avec animation et rendu en temps réel. Ce qui est revenu était... en fait plutôt bien. La physique de la voiture utilisait des raccourcis mathématiques astucieux pour simuler l'élan et le dérapage. La boucle de rendu était fluide. Le design de la piste était basique mais fonctionnel.
Puis j'ai poussé plus loin. Une simulation de dérapage de voiture de Formule 1 en 3D. C'est là que Flashlight a atteint ses vraies limites. La simulation était techniquement fonctionnelle — la voiture bougeait, la physique avait une certaine base dans la réalité et elle tournait sans crasher. Mais visuellement ? Ça ressemblait à un jeu PlayStation 1. Pas de manière rétro charmante. De la manière « ça a clairement atteint le plafond de complexité du modèle ».
Honnêtement, je m'y attendais. Générer des graphismes 3D convaincants à partir d'un seul prompt reste un problème incroyablement difficile, et Flashlight est explicitement optimisé pour la vitesse, pas pour repousser les limites de ce que le code généré par IA peut faire visuellement. Le fait qu'il ait produit quelque chose de fonctionnel est remarquable.
Mon avis honnête : N'utilisez pas Flashlight pour le développement de jeux complexes ou les simulations 3D riches. Utilisez-le pour les jeux 2D, les démos interactives et les prototypes visuels où la vitesse d'itération compte plus que le polish visuel.
Génération de Texte Long : Mieux que Prévu
J'ai demandé à Flashlight d'écrire un essai analytique sur la profondeur thématique du Seigneur des Anneaux, en se concentrant sur l'impact narratif et les fondements philosophiques. Pourquoi ce sujet ? Parce que l'analyse littéraire nécessite un raisonnement cohérent soutenu, un fil thématique et une conscience structurelle — exactement le type de chose que les modèles « light » ratent habituellement.
L'essai est revenu bien organisé, avec une thèse claire, des arguments qui se construisaient réellement les uns sur les autres et des références textuelles spécifiques. La prose n'allait pas gagner un Pulitzer, mais elle était considérablement meilleure que ce que Gemini 3 Flash avait produit pour le même prompt — et elle est arrivée visiblement plus vite.
Pour les développeurs qui construisent des outils de contenu, des pipelines de résumé ou des générateurs de documentation, c'est important. Vitesse plus qualité acceptable à l'échelle, c'est tout le jeu.
L'Intégration Kilo Code : Là où la Vitesse Rencontre le Workflow
L'une des choses qui m'a le plus impressionné n'était pas Flashlight lui-même — c'était sa qualité de fonctionnement au sein de l'outil CLI Kilo Code et de l'extension VS Code.
J'ai branché Flashlight sur le mode autonome de Kilo Code, où le modèle gère des chaînes de raisonnement multi-étapes : lecture de fichiers, exécution de vérifications, utilisation d'outils externes et génération d'output dans un workflow continu. L'expérience était remarquablement fluide.
Voici un exemple concret. Je lui ai demandé de générer une interface de navigateur style Mac OS avec des applications fonctionnelles basiques — une calculatrice, un bloc-notes et un explorateur de fichiers. Du prompt à l'output fonctionnel : 35 secondes. Coût total : 8 centimes.
Huit centimes. Pour une interface multi-composants et multi-applications avec une interactivité basique.
Les applications étaient-elles parfaitement polies ? Non. La calculatrice fonctionnait. Le bloc-notes était fonctionnel mais basique. L'explorateur de fichiers était plus un mockup statique qu'une vraie interface de système de fichiers. Mais comme point de départ pour itérer ? C'est un rapport coût-valeur incroyable.
L'intégration gère également la vérification de données en direct, ce qui signifie que le modèle peut vérifier ses propres outputs contre des sources de données réelles pendant la génération. C'est une capacité subtile mais puissante pour construire des workflows autonomes fiables.
Conseil de pro : Kilo Code offre actuellement 25$ de crédits d'utilisation gratuits pour leur outil CLI. Si vous allez tester Flashlight dans un vrai environnement de développement — et vous devriez — c'est le moyen le plus simple de le faire.
Ce que la Plupart des Gens Comprennent Mal sur Ce Modèle
Je veux être honnête sur quelque chose. Après avoir testé Flashlight de manière approfondie, je pense que la communauté des développeurs le juge mal dans deux directions opposées.
Le camp de l'enthousiasme le traite comme un modèle capable de remplacer les options de tier Pro pour tout. Il ne le peut pas. Le refactoring multi-fichiers complexe, le raisonnement architectural profond et le suivi nuancé d'instructions nécessitent toujours des modèles plus puissants. Si vous injectez Flashlight dans un workflow qui a véritablement besoin de raisonnement profond, vous serez frustré.
Les sceptiques le rejettent comme « juste un autre petit modèle » qui n'est utile que pour des projets jouets. C'est tout aussi faux. Pour les charges de travail spécifiques pour lesquelles il est optimisé — génération rapide, tâches à haut volume, applications en temps réel et prototypage front-end — Flashlight est véritablement la meilleure option disponible à son prix.
Le choix intelligent n'est pas de choisir Flashlight OU un modèle plus grand. C'est de construire une logique de routage qui envoie les bonnes tâches au bon modèle. Tâches de génération simples, prototypage UI, formatage de contenu, scaffolding de code basique — routez ceux-ci vers Flashlight. Raisonnement complexe, problèmes multi-contraintes, décisions architecturales — routez ceux-là vers Pro.
J'ai appris ça à mes dépens. Mon premier réflexe a été de tout passer par Flashlight parce que la vitesse était enivrante. En un jour, j'avais rencontré assez de cas limites pour réaliser que la sélection de modèle doit être spécifique à la tâche, pas universelle.
Voici la vérité inconfortable que personne ne veut admettre : le modèle qui est « le meilleur » dépend entièrement de ce que vous faites en ce moment, pas de ce qui a obtenu le score le plus élevé sur un leaderboard. L'ELO de 1400 de Flashlight n'a pas d'importance si votre tâche nécessite des capacités qu'il n'a pas. Et le raisonnement supérieur de Pro n'a pas d'importance si votre tâche est assez simple pour que vous ne fassiez que brûler de l'argent en calcul inutile.
La Vérification de Réalité des Prix
J'ai mentionné que Flashlight coûte 25$ par million de tokens d'entrée. Cela vaut la peine d'examiner plus attentivement.
Quand j'ai vu ces prix pour la première fois, j'ai eu une réaction mitigée. D'un côté, pour la performance obtenue, c'est compétitif. De l'autre, je m'attendais à ce que Google soit plus agressif vu le positionnement « light ». Des modèles dans ce tier d'efficience d'autres fournisseurs peuvent être moins chers.
Voici mon bilan après une journée d'utilisation réelle :
- Session légère de prototypage (15-20 générations de composants, niveau de réflexion bas) : environ 0,30-0,50$
- Session lourde de développement (tâches complexes multi-étapes, niveau de réflexion haut) : environ 2,00-4,00$
- Le projet de navigateur Mac OS (multi-étapes autonome avec Kilo Code) : 0,08$
Pour les développeurs individuels et les petites équipes, ces coûts sont triviaux. Pour les systèmes de production faisant des milliers d'appels par heure, les calculs deviennent plus intéressants — et c'est là que l'avantage de vitesse de Flashlight se compose réellement. Un time-to-first-token 2,5x plus rapide signifie que vos utilisateurs attendent moins, votre infrastructure gère plus de requêtes concurrentes et vos coûts de calcul par requête restent plus bas.
Mon calcul approximatif : basculer les charges de travail appropriées d'un modèle de tier Pro vers Flashlight m'a fait économiser environ 60-70% sur les coûts d'API tout en améliorant réellement les temps de réponse. Le compromis de qualité existait mais était acceptable pour les tâches que je lui ai routées.
Si Google baisse le prix de 20-30% — et la pression concurrentielle suggère qu'ils pourraient — cela devient un choix par défaut évident pour la majorité des appels API des développeurs.
Le Vrai Benchmark : Mon Workflow de Production
Les benchmarks vous disent ce qu'un modèle peut faire dans des conditions contrôlées. Ce qui m'intéresse réellement, c'est ce qu'il fait dans mon workflow de développement désordonné du monde réel.
Après une semaine de tests d'intégration, voici comment Flashlight a gagné une place permanente dans ma boîte à outils :
Sessions de prototypage matinales : Quand j'explore des idées, essaie différentes approches UI ou monte rapidement de nouvelles fonctionnalités, Flashlight est maintenant mon choix par défaut. La vitesse signifie que je peux itérer à travers 5-6 variations dans le temps qu'il fallait pour en générer une seule. Ce n'est pas une amélioration mineure — ça change fondamentalement ma façon d'aborder l'exploration de design.
Préparation de démos clients : Quand j'ai besoin de construire rapidement des prototypes interactifs à montrer aux clients, Flashlight plus Kilo Code m'emmène du concept à la démo cliquable en minutes. Ce n'est pas du code de production poli, mais assez convaincant pour une revue de design.
Pipelines de documentation et de contenu : Pour générer du contenu structuré, reformater des données et construire de la documentation à partir de commentaires de code, Flashlight gère 90% de mes besoins pour une fraction du coût.
Là où j'utilise encore des modèles plus grands : Sessions de debugging complexes où j'ai besoin que le modèle raisonne sur des patterns d'interaction subtils. Refactoring multi-fichiers où le contexte à travers de nombreux fichiers compte. Recommandations architecturales où je veux la « meilleure réflexion » du modèle, pas sa réflexion la plus rapide.
La combinaison de rapide-et-bon-marché plus lent-et-puissant est véritablement plus efficace que l'un ou l'autre seul. C'est comme avoir à la fois une voiture de sport et un utilitaire. Vous ne conduisez pas l'utilitaire au supermarché, et vous ne transportez pas du bois dans la voiture de sport.
Où Flashlight Se Situe dans la Famille Gemini 3
Pour donner du contexte, voici comment je positionnerais la gamme actuelle de Gemini 3 d'après mes tests :
Gemini 3.1 Pro — votre bête de somme. Raisonnement complexe, problèmes multi-contraintes, tâches où vous avez besoin du meilleur output absolu du modèle et le coût est secondaire. Je me tourne vers celui-ci quand la tâche est difficile et les enjeux sont élevés.
Gemini 3.1 Flashlight — votre sprinter. Génération à haut volume, prototypage rapide, applications en temps réel et toute tâche où la vitesse d'itération compte plus que la perfection au premier essai. C'est mon choix par défaut pour 60-70% des tâches de développement quotidiennes.
Gemini 3 Flash — le modèle efficient de la génération précédente. Il a encore sa place, mais Flashlight le surpasse en vitesse et en qualité dans virtuellement chaque test que j'ai effectué. Si vous utilisez encore Flash, mettez à jour.
La vitesse d'output 45% plus rapide et l'amélioration de 2,5x du time-to-first-token par rapport à Flash ne sont pas des améliorations incrémentales. Elles franchissent un seuil où le modèle semble véritablement temps réel. Les prompts qui donnaient l'impression d'« attendre l'IA » donnent maintenant l'impression d'« avoir une conversation ».
Ce changement perceptuel compte plus que n'importe quel chiffre de benchmark, parce qu'il change la façon dont les développeurs interagissent avec le modèle — et en fin de compte, ce qu'ils construisent avec.
Ma Prédiction : Le Pattern de Niveau de Réflexion Va Partout
J'ai mentionné le niveau de réflexion ajustable plus tôt, et je veux y revenir parce que je crois véritablement que c'est la fonctionnalité la plus visionnaire de Flashlight — et une que chaque grand fournisseur de modèles va copier dans les 12 prochains mois.
L'idée est simple : chaque requête n'a pas besoin de la même quantité de raisonnement. Un modèle qui peut ajuster dynamiquement son effort computationnel par requête n'est pas seulement plus efficient — il est plus utile. Vous obtenez essentiellement plusieurs modèles dans un seul endpoint API.
Je pense que nous nous dirigeons vers un monde où la sélection de modèle n'est pas « choisissez un modèle » mais « choisissez un budget de raisonnement ». Vous définirez un niveau de réflexion pour chaque appel API basé sur la complexité attendue, et le modèle allouera du calcul en conséquence.
Flashlight est le premier modèle que j'ai utilisé où ce n'est pas juste un concept théorique mais une fonctionnalité pratique prête pour la production. Et une fois que vous commencez à construire avec, revenir aux modèles à raisonnement fixe semble du gaspillage.
Les développeurs qui maîtriseront l'allocation dynamique de raisonnement en premier auront un avantage significatif en coûts et en vitesse. C'est le pattern à surveiller.
Ce que Je Dirais à un Développeur qui Considère Flashlight
Si vous hésitez, voici ma recommandation honnête.
Commencez par identifier les 30-40% de vos appels API IA actuels qui sont « simples » — formatage, génération basique, code mono-composant, transformation de données. Routez ceux-là vers Flashlight aujourd'hui. Mesurez les économies de coûts et les améliorations de vitesse. Vous verrez des retours immédiats.
Puis étendez progressivement. Testez-le sur vos workflows de prototypage. Essayez-le pour la génération de documentation. Intégrez-le dans votre pipeline CI/CD pour des commentaires automatiques de code review ou la génération de tests.
Vous trouverez la limite où la qualité de Flashlight tombe en dessous de votre seuil. Cette limite est votre point de bascule — tout en dessous va à Flashlight, tout au-dessus reste avec votre modèle actuel.
Cette limite est plus haute que vous ne le pensez. Je m'attendais à atteindre les limites de Flashlight rapidement. Au lieu de cela, il a géré environ 65% de ma charge de travail quotidienne aussi bien ou comparablement aux modèles plus lourds que j'utilisais avant — et pour une fraction du coût et de la latence.
Le modèle est disponible via Google AI Studio, l'API Gemini, OpenRouter et l'extension CLI/VS Code de Kilo Code. Ma recommandation : commencez avec les crédits gratuits de Kilo Code pour le tester dans votre vrai environnement de développement, puis passez à l'accès API direct une fois que vous avez validé l'adéquation.
Trois cent soixante-trois tokens par seconde. J'ai commencé cet article en pensant que ce chiffre était du marketing exagéré. Après une semaine à livrer du vrai code avec Flashlight comme moteur principal de génération, je pense que c'est peut-être la spécification la plus pratiquement pertinente en IA en ce moment. Pas parce que la vitesse est tout — mais parce qu'une fois que la génération est assez rapide pour sembler instantanée, vous arrêtez d'attendre et commencez à construire. Et ça change ce qui est possible.
Travaillons Ensemble
Vous cherchez à construire des systèmes d'IA, automatiser des workflows ou faire évoluer votre infrastructure technologique ? Je serais ravi de vous aider.
- Fiverr (développements sur mesure et intégrations) : fiverr.com/s/EgxYmWD
- Portfolio : mejba.me
- Ramlit Limited (solutions entreprise) : ramlit.com
- ColorPark (design et branding) : colorpark.io
- xCyberSecurity (services de sécurité) : xcybersecurity.io
