GPT 5.4 Testé : Le Meilleur Modèle d'IA pour Coder Actuellement ?

GPT 5.4 Testé : Le Meilleur Modèle d'IA pour Coder Actuellement ?

Il y a trois jours, j'ai chargé un monolithe Laravel entier — 847 fichiers, environ 120 000 lignes de code — dans une seule fenêtre de contexte GPT 5.4. Pas de découpage. Pas de résumés. Pas de contournements "voici le fichier pertinent" que je pratiquais depuis des années. Juste tout le codebase, brut, déversé dans une session.

Puis je lui ai demandé de trouver une condition de concurrence dans mon queue worker qui hantait la production depuis deux semaines.

Il a trouvé le bug en quatre-vingt-dix secondes. Pas une supposition. Pas un "ça pourrait être le problème." Il a tracé le chemin d'exécution à travers quatre services, identifié le moment exact où deux workers pouvaient saisir le même job, et écrit un correctif avec un verrou advisory au niveau de la base de données que j'avais été trop têtu pour envisager. Je suis resté à fixer mon écran pendant une minute entière avant même de tester le patch.

Ce moment — ce spécifique et viscéral "attends, qu'est-ce qui vient de se passer ?" — c'est la raison pour laquelle j'écris ce post. GPT 5.4 n'est pas une mise à jour incrémentale. C'est le premier modèle d'IA de programmation qui m'a fait genuinement repenser la façon dont je structure tout mon workflow de développement. Mais il n'est pas parfait, et une partie du battage médiatique qui l'entoure est déjà en train de déraper. J'ai besoin de séparer ce qui est réel du bruit marketing, parce que si vous êtes sur le point de réorganiser votre chaîne d'outils autour de ce modèle, vous méritez une évaluation honnête de quelqu'un qui l'a réellement mis à l'épreuve.

La Fenêtre de Contexte d'Un Million de Tokens Change Tout dans Votre Façon de Travailler

Je me plains des limitations de fenêtre de contexte depuis le plafond original de 8K tokens de GPT-4 en 2023. Chaque outil de programmation IA que j'ai utilisé nécessitait une version de la même danse : sélectionner soigneusement quels fichiers inclure, écrire des résumés détaillés des parties qui ne rentrent pas, et prier pour que le modèle n'hallucine pas de connexions entre du code qu'il ne peut pas réellement voir. Avec Claude Code et Opus 4.6, la gestion du contexte est devenue plus intelligente — l'outillage gère beaucoup automatiquement — mais la contrainte fondamentale était toujours là. Vous travailliez toujours avec une image partielle.

GPT 5.4 supporte jusqu'à un million de tokens de contexte. Ce n'est pas un maximum théorique enterré dans la documentation. C'est une fenêtre de contexte utilisable et pratique que j'ai remplie avec de vrais codebases à plusieurs reprises au cours de la dernière semaine.

Voici ce qui change quand le contexte cesse d'être un goulot d'étranglement.

Premièrement, vous arrêtez de réfléchir à ce qu'il faut inclure. J'avais l'habitude de passer cinq à dix minutes au début de chaque session complexe de débogage à décider quels fichiers étaient pertinents. Parfois je me trompais, réalisais en cours de route que j'avais besoin d'un fichier de configuration ou d'un middleware que je n'avais pas inclus, et devais relancer la conversation. Avec GPT 5.4, je charge simplement tout. Le modèle détermine ce qui est pertinent. Cette fatigue décisionnelle disparaît complètement.

Deuxièmement, les préoccupations transversales deviennent triviales à analyser. Vous voulez comprendre comment l'authentification circule dans toute votre application ? Comment une seule variable d'environnement se propage à travers les configurations, services et scripts de déploiement ? Des questions qui nécessitaient auparavant de tracer manuellement des chemins à travers des dizaines de fichiers — GPT 5.4 y répond simplement. Il a l'image complète. Il peut voir la migration de base de données, le modèle, le contrôleur, la route API, l'appel frontend et le test, tout simultanément.

Troisièmement — et cela m'a surpris — la qualité de génération de code du modèle s'améliore dramatiquement quand il peut voir plus de contexte. J'ai fait une expérience informelle : j'ai demandé à GPT 5.4 d'ajouter une nouvelle fonctionnalité à un projet deux fois. Une fois avec seulement les fichiers pertinents (environ 15 fichiers, peut-être 3 000 tokens de code). Une fois avec tout le codebase chargé. La seconde tentative a produit du code qui correspondait à mes patterns existants, utilisait mes fonctions helper personnalisées au lieu de les réinventer, et suivait les conventions de nommage que j'avais établies des mois auparavant. La première tentative a produit du code générique, correct mais étranger. Même modèle. Même prompt. La seule différence était le contexte.

Je dois mentionner la contrainte pratique ici : charger un million de tokens n'est pas gratuit. Les coûts d'API augmentent avec les tokens d'entrée, et charger tout le codebase à chaque interaction brûlerait les crédits rapidement. Pour les sessions exploratoires et le débogage complexe, ça vaut chaque centime. Pour les tâches routinières "écris cette fonction", vous surpayez. Je me suis installé dans un rythme où je charge le codebase complet pour le travail d'architecture et j'utilise des contextes plus petits et ciblés pour le code au quotidien. Cet équilibre me semble juste — mais vous devrez trouver le vôtre.

Computer Use : Quand Votre IA Commence à Tester Son Propre Code

C'est la fonctionnalité qui m'a fait me redresser sur ma chaise. GPT 5.4 peut interagir avec des applications comme le ferait un humain — en cliquant sur des boutons, lisant des écrans, naviguant dans des interfaces. OpenAI appelle ça "computer use," et bien que le nom sonne comme du jargon marketing, la capacité est genuinement un territoire nouveau pour un modèle de programmation.

Je l'ai testé sur un dashboard React que je construis. J'ai demandé à GPT 5.4 d'ajouter une fonctionnalité d'export de données, et au lieu de juste écrire le code et me le rendre, il a écrit le code, ouvert l'application dans un navigateur, navigué vers le dashboard, cliqué sur le bouton d'export qu'il venait de créer, vérifié que le CSV se téléchargeait correctement, remarqué que le formatage de date était faux dans une colonne, est retourné corriger le code, puis a retesté. Tout ça sans que je touche à quoi que ce soit.

Soyons réaliste sur l'état actuel : c'est impressionnant mais pas prêt pour la production dans des workflows de test complexes. Le modèle gère bien les interactions UI simples — remplissage de formulaires, clics sur boutons, navigation. Mais il a du mal avec les applications qui reposent beaucoup sur les états hover, le glisser-déposer, ou le timing d'animations complexes. Je lui ai fait essayer de tester une fonctionnalité de tableau Kanban et il ne pouvait pas déplacer les cartes entre colonnes de manière fiable. Il savait ce qu'il voulait faire. Les compétences motrices n'étaient pas encore là.

Là où le computer use brille déjà, c'est dans la boucle de feedback qu'il crée. Traditionnellement, le workflow de programmation IA se déroule ainsi : écrire le code → tester manuellement → rapporter les problèmes à l'IA → itérer. L'étape du milieu — le test manuel — est celle qui prend le plus de temps. Non pas parce que tester est difficile, mais parce que traduire des résultats visuels en descriptions textuelles pour l'IA est lent et avec perte d'information. "Le bouton est là mais il est mal positionné" perd de l'information comparé au modèle qui voit réellement le bouton.

Le computer use de GPT 5.4 effondre cette boucle. Le modèle écrit, teste, voit le résultat et itère — tout dans une seule interaction. Pour les fonctionnalités simples, cela réduit le cycle de développement de quatre étapes à une. J'ai construit et testé un formulaire de contact complet — validation, états d'erreur, message de succès, envoi d'email — en un seul prompt. Le modèle a fait trois itérations de lui-même avant de présenter la version finale. Chaque itération a corrigé de vrais problèmes qu'il a découverts en utilisant réellement le formulaire.

Je m'attends à ce que cette capacité s'améliore rapidement. Le modèle de vision sous-jacent est solide. La couche d'interaction a juste besoin de polissage. Dans six mois, je soupçonne que le computer use sera un prérequis pour les modèles d'IA de programmation. GPT 5.4 y est arrivé en premier, et même dans sa forme actuelle, il a changé ma façon de penser la phase de test du développement.

Les Modes de Raisonnement qui Comptent Vraiment

GPT 5.4 est livré avec des modes de raisonnement sélectionnables — "high" et "ultra-high" — et ma réaction initiale a été le scepticisme. Les modes de raisonnement ressemblaient à une case à cocher marketing. "Notre modèle réfléchit plus fort si vous lui demandez gentiment." Mais après avoir utilisé les deux modes de manière intensive, j'ai changé d'avis. La différence est réelle, mesurable et mérite d'être comprise.

Le mode de raisonnement high est ce que vous voulez pour 80% des tâches de programmation. Écrire des fonctions, refactoriser du code, générer des tests, expliquer de la logique complexe. C'est rapide, précis et fiable. Les temps de réponse sont comparables à ce que j'ai expérimenté avec d'autres modèles de premier plan — vous n'attendez pas.

Le mode de raisonnement ultra-high est pour les problèmes qui vous font fermer votre laptop et aller marcher. Les décisions architecturales avec des implications en cascade. Le débogage de conditions de concurrence dans des systèmes concurrents. L'analyse de vulnérabilités de sécurité à travers un codebase entier. L'optimisation de performance quand le goulot d'étranglement n'est pas évident. Ce sont des problèmes où "réfléchir plus fort" produit effectivement des réponses différentes — et meilleures.

J'ai fait une comparaison directe sur un problème réel : optimiser une requête de base de données qui prenait 14 secondes sur une table de 2,3 millions de lignes. En mode high, GPT 5.4 a suggéré d'ajouter un index et de réécrire une sous-requête en JOIN. Conseil d'optimisation standard. Correct, mais j'avais déjà essayé les deux. En mode ultra-high, le même modèle a analysé le plan d'exécution de la requête, identifié que l'optimiseur choisissait un hash join alors qu'un merge join serait plus rapide étant donné la distribution des données, suggéré un hint de requête pour forcer le merge join, recommandé un index partiel sur la colonne filtrée, et souligné que ma clause WHERE empêchait l'utilisation de l'index à cause d'un cast de type implicite que je n'avais pas remarqué. La réponse ultra-high a pris environ douze secondes de plus. Elle m'a économisé environ trois heures d'analyse manuelle de requêtes.

La leçon que j'en tire : ne passez pas en ultra-high par défaut. Commencez avec high. Escaladez quand vous êtes bloqué ou quand le problème nécessite genuinement une analyse plus approfondie. Le mode ultra-high utilise plus de tokens et prend plus de temps — c'est un outil, pas un réglage à laisser permanemment activé. Mais quand vous en avez besoin, la différence entre "bonne suggestion" et "c'est exactement l'insight qui me manquait" vaut l'attente.

GPT 5.4 vs Opus 4.6 : La Comparaison Honnête que Personne ne Veut Faire

J'utilise les deux. Quotidiennement. Je ne vais pas prétendre que l'un est catégoriquement meilleur que l'autre, parce que ce serait malhonnête et inutile. Voici ce que j'ai trouvé après des semaines à faire tourner les deux modèles sur les mêmes projets.

GPT 5.4 gagne sur la complexité backend. Pour les gros codebases, le débogage complexe, les architectures multi-services et les tâches qui nécessitent de maintenir de grandes quantités de contexte simultanément, GPT 5.4 est actuellement le modèle le plus fort. La fenêtre de contexte d'un million de tokens est l'avantage évident, mais ce n'est pas qu'une question de capacité. La capacité du modèle à raisonner à travers des parties distantes d'un codebase — connectant un changement de schéma de base de données à ses effets en cascade à travers une couche API, un système de gestion d'état frontend et une suite de tests — semble qualitativement différente de ce que j'obtiens avec d'autres modèles.

Opus 4.6 gagne sur le frontend et le travail UI. Ça m'a surpris, honnêtement. Je m'attendais à ce que GPT 5.4 domine sur tous les fronts. Mais quand je construis des composants React, conçois des layouts, travaille avec des animations CSS ou itère sur du design visuel, Opus 4.6 produit systématiquement de meilleurs résultats. Les composants ont l'air plus soignés. Le CSS est plus propre. La sensibilité design — et je réalise que j'attribue un jugement esthétique à un modèle d'IA — semble plus raffinée. J'ai testé cela plusieurs fois, alternant entre les modèles sur la même tâche UI, et le pattern se confirme.

Les deux modèles gèrent le travail de développement standard aussi bien l'un que l'autre. Pour les tâches quotidiennes — endpoints CRUD, migrations de base de données, tests unitaires, documentation, revues de code — je ne peux genuinement pas distinguer de différence significative. Choisissez le modèle qui s'intègre à votre workflow existant.

Voici ma configuration actuelle, au cas où ça aiderait : j'utilise GPT 5.4 via Cursor pour le travail backend et les sessions de débogage complexes. Je reste sur Claude Code avec Opus 4.6 pour le développement frontend, les workflows basés sur les agents, et tout ce qui bénéficie de l'excellente gestion de contexte de projet de Claude Code. Quand je démarre une nouvelle fonctionnalité qui couvre à la fois frontend et backend, je commence typiquement avec GPT 5.4 pour l'architecture et la couche API, puis je passe à Opus 4.6 pour l'implémentation UI.

Est-ce optimal ? Probablement pas. Vais-je consolider vers un seul modèle un jour ? Peut-être. Mais en ce moment, les forces de chaque modèle sont suffisamment différentes pour qu'utiliser les deux produise un meilleur travail que s'engager exclusivement avec l'un ou l'autre.

Matt Shumer — CEO de HyperWrite et quelqu'un dont je fais généralement confiance aux évaluations techniques — a qualifié GPT 5.4 de "essentiellement parfait" et a dit que la programmation est "résolue." Je pense que c'est environ 70% correct. Le modèle est étonnamment capable. Mais "résolu" implique qu'il n'y a rien à améliorer, et je peux pointer au moins une douzaine d'interactions de cette semaine où le modèle a produit du code subtilement faux, mal compris une contrainte, ou eu besoin de multiples itérations pour arriver au bon résultat. C'est le meilleur modèle d'IA de programmation que j'ai utilisé. Il n'est pas parfait. L'écart entre "le meilleur disponible" et "impeccable" est toujours réel, et il compte quand vous déployez du code en production.

Démarrer Sans Perdre Vos Deux Premières Heures

J'ai gaspillé ma première session avec GPT 5.4 parce que je ne comprenais pas le paysage d'outils. Laissez-moi vous faire gagner ce temps.

Étape 1 : Choisissez votre interface. Vous avez trois options principales en ce moment.

L'app Codex est l'interface de programmation dédiée d'OpenAI. Malgré le nom, l'app n'utilise plus un modèle "Codex" séparé — vous sélectionnez GPT 5.4 dans un menu déroulant au sein de l'app. Ça m'a confus initialement parce que je cherchais une option de modèle Codex dédiée qui n'existe plus. L'app se connecte directement à vos dépôts GitHub, ce qui signifie que vous pouvez importer votre codebase sans téléchargements manuels. Pour le travail au niveau projet — revues d'architecture, refactorisations majeures, planification de fonctionnalités — l'app Codex est probablement votre meilleur point de départ.

Cursor est là où je fais la plupart de mon travail avec GPT 5.4. Si vous êtes déjà utilisateur de Cursor, l'intégration est transparente — GPT 5.4 apparaît comme option dans le sélecteur de modèles. La force de Cursor est l'assistance de programmation inline : vous écrivez du code, vous surlignez un bloc, vous posez une question, vous obtenez une réponse en contexte. La vitesse et la précision de GPT 5.4 rendent ce flux particulièrement fluide. Si vous venez de VS Code avec Copilot, Cursor avec GPT 5.4 est une montée en gamme significative.

L'API directement est la troisième option, et c'est ce que j'utilise pour les workflows automatisés. J'ai des scripts qui exécutent GPT 5.4 pour la revue de code sur les pull requests, la génération automatisée de tests pour les nouveaux fichiers, et les mises à jour de documentation quand les APIs changent. L'API vous donne un contrôle total sur la gestion du contexte, les prompts système et le formatage de sortie. C'est plus de travail à configurer, mais la flexibilité est inégalée.

Étape 2 : Préparez votre codebase. Si votre code est sur GitHub, l'app Codex et Cursor peuvent se connecter directement. Pour Cursor, ouvrez simplement le dossier de votre projet local. Pour l'app Codex, connectez votre compte GitHub et sélectionnez le dépôt. Si vous n'utilisez pas GitHub, téléchargez votre codebase en ZIP, extrayez-le localement et ouvrez-le dans Cursor. Je recommande d'avoir une copie locale propre et à jour quelle que soit l'outil que vous utilisez.

Étape 3 : Commencez avec le mode de raisonnement high. Ne sautez pas directement à ultra-high. Le mode high gère 80% des tâches de programmation efficacement, et vous aurez des réponses plus rapides. Réservez ultra-high pour quand vous êtes genuinement bloqué sur un problème complexe — vous saurez quand vous en avez besoin parce que les suggestions du mode high ne résoudront pas votre vrai problème.

Étape 4 : Testez avec une vraie tâche, pas un exemple jouet. La pire façon d'évaluer GPT 5.4 est de lui demander d'écrire une app de tâches ou d'inverser une chaîne. Ces tâches n'exercent pas ses vraies forces. Prenez plutôt un vrai bug que vous repoussez, ou une fonctionnalité qui nécessite des changements dans plusieurs fichiers, ou un problème de performance que vous n'avez pas eu le temps d'investiguer. C'est là que GPT 5.4 justifie sa réputation.

Conseil pro : Si vous migrez d'un autre outil de programmation IA, n'essayez pas de reproduire votre workflow exact. La fenêtre de contexte de GPT 5.4 est tellement plus grande que ce à quoi vous êtes habitué que vos anciennes habitudes — sélectionner soigneusement quels fichiers inclure, écrire des résumés détaillés de votre architecture — sont de la surcharge inutile. Laissez le modèle tout voir. Laissez-le déterminer ce qui est pertinent. C'est inconfortable au début, comme lâcher le volant. Mais le modèle navigue mieux avec la carte complète que vous avec un itinéraire surligné.

Les Limitations Honnêtes Dont Personne ne Parle

J'ai été enthousiaste à propos de GPT 5.4 tout au long de ce post. Intentionnellement, parce que le modèle le mérite. Mais je vous rendrais un mauvais service si je ne parlais pas de ce qui est encore cassé, limité ou frustrant.

La qualité de design frontend n'y est pas encore. J'ai mentionné cela dans la comparaison avec Opus, mais ça mérite d'être répété parce que beaucoup de gens misent tout sur GPT 5.4 pour tout. Si vous construisez des interfaces utilisateur — surtout tout ce qui doit avoir l'air soigné, être responsive et gérer les cas limites de mise en page avec grâce — GPT 5.4 vous donnera des résultats fonctionnels mais visuellement médiocres. Le CSS qu'il génère fonctionne. Les composants s'affichent correctement. Mais les choix de design sont sûrs, génériques et sans inspiration. Opus 4.6 est nettement meilleur ici, et les outils UI dédiés comme les workflows Figma-to-code produisent encore des résultats visuels supérieurs.

La fenêtre d'un million de tokens a un problème de coût. J'ai fait allusion à cela plus tôt, mais soyons explicite : charger 500K+ tokens de contexte à chaque interaction est cher. Lors d'une session de débogage particulièrement intensive, j'ai brûlé ce que j'estime être 15-20$ en crédits API en environ trois heures. C'est acceptable pour moi — le bug que j'ai corrigé m'aurait pris une journée entière sans le modèle. Mais si vous êtes un développeur solo qui surveille ses coûts, vous avez besoin d'une stratégie pour savoir quand utiliser le contexte complet et quand être sélectif.

Les hallucinations n'ont pas disparu. Elles sont moins fréquentes avec GPT 5.4 qu'avec tout modèle que j'ai utilisé auparavant, mais elles arrivent encore. Mardi dernier, le modèle m'a dit avec confiance que Laravel 12 avait introduit une méthode Model::withoutTimestamps() pour les opérations en masse. Ce n'était pas le cas. La méthode n'existe pas. La suggestion était assez plausible pour que je passe quinze minutes à la chercher dans la documentation avant de réaliser que le modèle l'avait inventée. Vérifiez toujours. Faites confiance mais vérifiez. Le modèle est plus intelligent que toute version précédente, mais il est toujours capable de fiction créative quand il rencontre des lacunes dans ses données d'entraînement.

Les tâches de longue durée peuvent dériver. Dans les sessions prolongées — imaginez deux heures d'échanges continus sur une fonctionnalité complexe — j'ai remarqué que le modèle perd parfois le fil des décisions prises plus tôt dans la conversation. Il suggère une approche qui contredit quelque chose que nous avions déjà convenu être erroné. La fenêtre d'un million de tokens aide parce qu'il peut techniquement "voir" la discussion antérieure, mais l'attention sur de très longs contextes n'est pas uniforme. Les décisions importantes au début d'une longue session peuvent recevoir moins de poids que les messages récents. Ma solution : pour les décisions architecturales critiques, je les énonce explicitement comme contraintes au début de chaque phase majeure de travail. "Nous avons décidé X. Nous ne revenons pas là-dessus. Maintenant travaillons sur Y."

Pas d'intégration Anti-Gravity pour l'instant. Si vous êtes dans l'écosystème Anthropic et utilisez Anti-Gravity pour orchestrer des workflows multi-modèles, GPT 5.4 n'y est pas encore disponible. Cela pourrait changer — le paysage de l'outillage IA évolue vite — mais à ce jour, utiliser GPT 5.4 signifie sortir de la chaîne d'outils Anthropic pour ces tâches spécifiques. Pour moi, cela signifie maintenir deux workflows séparés, ce qui ajoute de la friction.

Je liste ces limitations non pas pour discréditer le modèle mais parce que j'ai vu trop d'avis "GPT 5.4 est parfait, la programmation est résolue" en ligne. C'est le meilleur modèle d'IA de programmation disponible actuellement. C'est aussi un outil avec de vraies contraintes que vous devez comprendre avant de construire votre workflow autour de lui.

Ce que Cela Signifie pour les Six Prochains Mois

Je construis avec des outils de programmation IA depuis le premier aperçu de l'API GPT-4. Tous les quelques mois, il y a un modèle qui m'oblige à mettre à jour mon modèle mental de ce qui est possible. GPT 5.4 est l'un de ces moments.

La combinaison d'une fenêtre de contexte d'un million de tokens, des capacités de computer use et d'un raisonnement genuinement amélioré crée quelque chose qui se sent qualitativement différent de ce qui existait avant. Ce n'est pas juste un meilleur autocomplete. C'est plus proche d'un développeur junior qui peut lire tout votre codebase, tester son propre travail et expliquer son raisonnement quand on lui demande.

Voici ma prédiction, et je la revisiterai dans six mois : la prochaine vague d'outils de programmation IA ne rivalisera pas uniquement sur la qualité du modèle. GPT 5.4 et Opus 4.6 ont prouvé que plusieurs organisations peuvent produire des modèles de programmation de classe mondiale. Le différenciateur sera l'outillage — comment le modèle s'intègre dans votre workflow, comment il gère le contexte, comment il traite les tâches multi-étapes et comment il récupère des erreurs. Le modèle est le moteur. L'expérience développeur est la voiture. En ce moment, nous avons d'excellents moteurs dans des voitures médiocres.

Les développeurs qui bénéficieront le plus de GPT 5.4 ne sont pas ceux qui l'utilisent comme un autocomplete plus rapide. Ce sont ceux qui restructurent leurs workflows pour tirer parti de ses vraies forces : le raisonnement sur l'ensemble du codebase, les tests autonomes et l'analyse approfondie de problèmes complexes. Cela nécessite de changer ses habitudes. Cela nécessite de laisser le modèle faire des choses que vous avez l'habitude de faire manuellement. Cela nécessite un niveau de confiance qui prend du temps à construire — et devrait prendre du temps, parce que la confiance aveugle dans n'importe quel outil est une recette pour déployer des bugs.

Si vous hésitez encore au sujet des outils de programmation IA, GPT 5.4 est le modèle qui devrait vous décider. Non pas parce qu'il est parfait. Parce qu'il est assez bon pour que ne pas l'utiliser vous place en désavantage mesurable face aux développeurs qui l'utilisent.

Et cette condition de concurrence dans mon queue worker ? Celle que j'ai passé deux semaines à déboguer manuellement ? Le correctif de GPT 5.4 tourne en production depuis cinq jours maintenant. Zéro incident. Zéro job échoué. L'approche par advisory lock était plus propre que tout ce que j'aurais écrit moi-même, et le modèle a mis quatre-vingt-dix secondes à trouver une solution qui m'avait échappé pendant quatorze jours.

Je ne sais pas si ça me fait sentir brillant d'avoir utilisé le bon outil, ou humble que l'outil est meilleur à mon travail que moi. Probablement les deux. Définitivement les deux.

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