Nehos : ce que 2025 nous a appris et nos chantiers 2026 — lettre ouverte du fondateur

#2025 : l'année où l'IA est passée de l'expérimentation à la production

Quand je relis les notes que j'avais prises début 2025, je mesure à quel point les prédictions — y compris les miennes — étaient en retard sur la réalité. On parlait encore de «phase d'expérimentation», d'«exploration des cas d'usage», de «POC avant de décider». En practice, 2025 a été l'année où l'IA a brutalement changé de statut dans les projets que nous livrons : de technologie à évaluer à composant d'architecture de production.

Le marqueur le plus concret pour Nehos : les agents IA en production. Ce n'est pas une démo. Ce n'est pas un POC. C'est un système qui traite des demandes réelles, qui prend des décisions réelles, et dont les performances sont mesurées en continu. Ce que l'on mesure sur un agent en production, c'est la part de demandes résolues automatiquement : personne ne la croyait atteignable en production au départ, et c'est le premier indicateur à suivre.

Cette année nous a aussi appris ce qui marche vraiment versus ce qui fait de belles présentations. Les architectures RAG sans audit data préalable font de belles démos avec des données propres — et s'effondrent en production sur les données réelles des clients. Les agents autonomes multi-steps avec LangGraph sont puissants à condition d'avoir défini des guardrails précis dès la conception.

Les migrations legacy réussies ne sont pas des prouesses techniques — elles sont des projets de conduite du changement avec une composante technique.

À l'échelle de Nehos, l'important n'est pas un chiffre de volume mais la qualité de chaque mission. Les chiffres d'activité (nombre de projets, équipe, NPS, fidélisation) ne sont pas publiés dans cette lettre.

Les technologies que nous utilisons en production : Next.js 16, NestJS, LangGraph, Claude API, Mistral Large, pgvector, Medusa v2, Payload CMS. Pas des technologies expérimentales — des stacks de production avec des SLA et des astreintes.

---

#Cinq situations types de 2025

Pour donner de la substance à cette lettre, voici cinq situations types, construites pour illustrer ce que nous avons appris. Ce ne sont pas des projets clients, et aucun chiffre n'y est présenté comme un résultat.

#1. Agent IA sinistres — mutuelle

Une mutuelle de taille intermédiaire cherche à réduire le coût de traitement des sinistres de faible complexité tout en améliorant les délais de réponse. Après un audit data de quelques semaines (cette étape change tout), on déploie un agent IA capable de traiter les sinistres dont le montant est inférieur à un seuil défini, avec vérification de cohérence des pièces jointes via OCR et validation contre les conditions contractuelles.

Les indicateurs à suivre : la part des sinistres traitée automatiquement sans intervention humaine, et le temps de traitement des cas complexes, qui sont routés vers un gestionnaire avec un résumé pré-rempli. Le retour sur investissement se calcule à partir de ces deux mesures.

#2. Migration Oracle Forms → Next.js 16 — ETI industrie chimique

Plusieurs dizaines de formulaires Oracle Forms, une ETI de l'industrie chimique. Cette situation illustre ce qu'est une migration Oracle Forms réussie : pas un remplacement technique, mais une réécriture fonctionnelle qui profite de la migration pour supprimer les formulaires devenus obsolètes et moderniser les autres.

La stack envisagée — Next.js 16 App Router, NestJS pour le BFF, PostgreSQL avec un schéma largement refactorisé — vise des performances que l'équipe IT n'avait jamais vues sur son applicatif métier : temps de chargement maîtrisé, accessibilité RGAA niveau AA, déploiement CI/CD complet.

#3. Headless commerce B2B — distributeur industriel

Un distributeur industriel avec plusieurs milliers de références veut offrir à ses clients B2B un portail de commande en ligne digne de ce nom. L'ancien site — un CMS générique non adapté au B2B — convertit mal. Sur une stack headless commerce B2B (Medusa v2 + Next.js 16 + PIM custom), le nouveau portail apporte des fonctionnalités B2B natives : gestion multi-comptes, approbation de commandes, catalogues personnalisés par client. L'indicateur à suivre est le taux de conversion avant/après.

#4. Dashboard trésorerie multi-banques — ETI

Réconciliation de trésorerie multi-banques pour une ETI qui opère avec plusieurs établissements bancaires. Le processus existant : des exports CSV manuels, des tableaux Excel, plusieurs jours de travail par semaine pour la direction financière. La solution : un dashboard Next.js connecté via l'API Bridge/Tink pour l'agrégation bancaire, avec réconciliation automatique et alertes en temps réel. L'indicateur à suivre est le temps passé chaque semaine.

#5. SIRH sur mesure — plusieurs conventions collectives

Un SIRH SaaS générique ne gère pas correctement plusieurs conventions collectives simultanées. Après évaluation des alternatives (les SIRH sur mesure vs SaaS existants ont souvent le même problème), la décision est de développer un module de paie sur mesure, intégré au SIRH existant pour le reste des fonctions.

Les indicateurs à suivre : les tâches administratives RH, les erreurs de paie, le nombre de bulletins générés automatiquement.

---

#Ce qui n'a pas fonctionné — et ce qu'on a appris

Je pourrais ne parler que des succès. Ce serait plus confortable. Ce serait aussi moins utile pour quiconque évalue Nehos comme partenaire potentiel.

Deux types de projets échouent régulièrement. Voici deux situations types.

#Situation type n°1 — Chatbot SAV B2C, grande distribution

Un acteur de la grande distribution voulait déployer un chatbot SAV capable de traiter les demandes de retour, les réclamations et les questions produits. Le projet semblait solide : volumétrie importante, cas d'usage bien définis, budget adapté.

Problème : la qualité des données est catastrophique. Les fiches produits sont très incomplètes. Les historiques de commandes contiennent des incohérences accumulées sur des années. Les bases de connaissance SAV sont dispersées dans des wikis, des emails et des têtes de collaborateurs jamais formalisées.

Si ce problème est identifié tard, il est déjà trop tard pour sauver le planning. C'est la leçon la plus importante : un audit RAG et un audit data doivent précéder tout engagement de développement sur un projet IA. Pas parce que les données seront parfaites — elles ne le sont jamais — mais pour savoir si elles sont suffisamment exploitables pour tenir les promesses du projet.

Quand le projet s'arrête, il vaut mieux que la décision soit mutuelle et sans contentieux. Ce n'est pas agréable, mais c'est juste.

Ce que nous avons changé dans notre méthodologie : tout projet IA commence par une semaine d'audit data avant tout engagement de développement. Pas optionnel.

#Situation type n°2 — Migration microservices, ETI agroalimentaire

Une ETI agroalimentaire de taille significative voulait migrer son ERP maison monolithique vers une architecture microservices. Le projet était techniquement faisable — nous avions l'équipe, la méthode, la stack.

Ce qui tue le projet : la résistance organisationnelle. Le DSI est convaincu. La direction générale est d'accord en principe. Mais les directeurs de production, de logistique et de finance — les utilisateurs réels des systèmes — ne sont impliqués ni dans la décision ni dans la conception.

Les ateliers de validation fonctionnelle tournent systématiquement en réunions de blocage. Les délais de validation s'allongent. Les demandes de modifications fondamentales arrivent sur des spécifications déjà validées.

Le diagnostic est clair : le change management précède l'architecture. On ne peut pas concevoir une migration de système de production sans que les équipes opérationnelles soient co-décisionnaires du design.

Ce que nous avons changé dans notre méthodologie : tout projet de migration legacy de complexité élevée inclut une phase d'alignement organisationnel avant la conception technique. Cartographie des parties prenantes, identification des résistances, mise en place d'un comité de gouvernance avec représentation opérationnelle. Pas de conception avant validation de cette phase.

---

#Les indicateurs que nous suivons

Nous ne publions pas ici de chiffres d'activité. Voici les indicateurs que nous suivons pour juger de la santé de notre activité :

• Qualité de livraison : respect des engagements de moyens et de délais
• Satisfaction clients : mesurée en fin de projet et à 3 mois post-livraison
• Fidélisation : part des clients qui démarrent un nouveau projet
• Technologies en production : Next.js 16, NestJS, LangGraph, Claude API, Mistral Large, pgvector, Medusa v2, Payload CMS

Nous nous fixons des objectifs d'amélioration sur les sources de friction identifiées en 2025 : délais de démarrage trop longs, documentation de handover insuffisante.

---

→ Pour aller plus loin : découvrez nos outils gratuits — calculateurs ROI, diagnostics techniques et quiz interactifs pour affiner votre réflexion.

#Les tendances tech qui nous ont surpris en 2025

Cinq observations de terrain qui ne figuraient dans aucun rapport de cabinet de conseil.

1. Claude Code a accéléré notre développement interne. Je ne m'y attendais pas à ce niveau. L'impact le plus significatif n'est pas sur le code boilerplate — c'est sur le debugging et la revue de code, qui prenaient une part disproportionnée du temps des seniors.

2. Mistral Large s'est imposé pour les projets souveraineté. Pour les clients qui ont des contraintes de souveraineté des données (et ils sont de plus en plus nombreux, anticipant l'AI Act), Mistral Large est devenu notre premier choix. La qualité est très proche de GPT-4o sur les cas d'usage que nous traitons, le déploiement on-premise est réel, et le coût est significativement inférieur. Ce n'était pas évident début 2025.

3. Next.js App Router est maintenant mature — la résistance des équipes a disparu. Il y a quelque temps, chaque projet Next.js commençait par une discussion sur Pages Router vs App Router. En 2025, cette discussion n'a presque plus lieu. L'écosystème a rattrapé son retard, la documentation est solide, et les devs qui l'ont utilisé ne veulent plus revenir en arrière.

4. pgvector a remplacé Pinecone pour nos projets RAG on-premise. Pour les projets RAG où les données restent on-premise — la majorité des cas ETI — pgvector dans PostgreSQL remplace Pinecone dans notre stack. Moins de composants à maintenir, performances suffisantes pour les volumétries ETI, et une seule base de données pour les données structurées et les embeddings. La simplicité opérationnelle l'emporte sur les benchmarks de perfs.

→ Pour aller plus loin : découvrez nos outils gratuits — calculateurs ROI, diagnostics techniques et quiz interactifs pour affiner votre réflexion.

5. La fatigue des POC. Le signal le plus net de 2025 côté clients : la patience pour les preuves de concept est courte. Si un projet ne montre pas une valeur concrète en production ou en pré-production, les budgets se ferment. Cette dynamique change notre manière de cadrer les projets : on ne propose plus de POC ouverts — on propose des « Sprint Valeur » de quelques semaines avec un livrable fonctionnel défini à l'avance et des critères de go/no-go explicites.

---

#Ce que les clients nous demandent en 2026

Voici les demandes que nous entendons le plus souvent et qui orientent notre offre 2026 :

• Un agent IA opérationnel en production
• La conformité DORA/AI Act comme moteur de projet
• La migration d'un système legacy — le plus souvent un ERP maison, un Oracle Forms ou un COBOL
• L'ouverture à l'export (Luxembourg, Belgique, Allemagne principalement)

Ce qui ressort de manière transversale : la patience pour les POC est épuisée. Les clients veulent des projets qui vont en production. Ils ne veulent plus payer pour apprendre — ils veulent payer pour des résultats. Cette pression est saine. Elle correspond exactement à ce que nous cherchons à livrer.

Autre signal fort : la transformation digitale n'est plus perçue comme un projet DSI. De plus en plus souvent, c'est le PDG ou le DG qui initie l'échange. La transformation digitale est devenue un sujet de comité de direction, pas de département informatique.

---

#Notre positionnement 2026 : partenaire tech de la transformation

Nehos en 2026 n'est plus simplement une agence de développement sur mesure. Ce positionnement était juste en 2022, partiellement juste en 2024, et ne reflète plus la réalité de ce que nous faisons aujourd'hui.

La transformation digitale d'une ETI requiert trois capacités simultanées : le conseil (stratégie IA, conformité réglementaire DORA/AI Act, priorisation des investissements), l'ingénierie (Next.js 16, agents IA, migration legacy, commerce headless), et la plateforme (des briques réutilisables qui accélèrent la mise en production). Nehos investit aujourd'hui dans les trois.

La Nehos Agent Platform — notre plateforme de déploiement et de monitoring d'agents IA — répond à un problème concret rencontré sur les projets agents : le déploiement est relativement bien adressé par l'écosystème, mais le monitoring en production, la gestion des guardrails, la traçabilité des décisions et la mise à jour des agents sans interruption de service le sont moins. C'est ce problème que la Nehos Agent Platform cherche à résoudre.

Côté modèle commercial, nous investissons davantage dans les partenariats long terme (abonnements incluant ingénierie + conseil + accès plateforme) au détriment des projets one-shot ponctuels. La raison est simple : les clients avec qui nous avons les meilleures relations sont ceux avec qui nous travaillons sur la durée.

Concernant le refactor IA assisté : l'IA dans notre propre process de développement fait baisser les coûts sur certains projets. Nous sommes transparents sur ce point avec nos clients, et nous répercutons une partie de ces gains dans nos tarifs.

Cela ne veut pas dire que les projets sont simples — cela veut dire qu'ils sont maintenant accessibles à des ETI qui n'auraient pas pu se les offrir il y a quelques années.

---

#Ce que nous voulons construire en 2026

Quelques chantiers pour l'année :

1. Nehos Agent Platform. Faire passer la plateforme à un stade de disponibilité plus large : documentation publique, onboarding client autonome, pricing transparent. La plateforme s'adresse aux ETI qui veulent déployer des agents IA en production sans créer une équipe MLOps interne.

2. Travailler avec des entreprises du Luxembourg et de la Belgique. Nous travaillons avec des entreprises de ces pays, à distance et sur place lorsque le projet le demande. Il existe une demande pour une expertise francophone en transformation digitale ETI, notamment sur les sujets de conformité (DORA est particulièrement critique dans le secteur financier luxembourgeois).

3. Startup Studio. Dans le prolongement de notre Startup Studio, nous souhaitons co-créer de nouveaux projets avec des fondateurs issus de notre réseau ETI, notamment en fintech B2B et en automatisation pour le secteur de la santé.

4. Renforcer l'équipe. Pour tenir nos objectifs 2026, nous recherchons des profils d'ingénieurs IA (LangGraph, RAG, évaluation de modèles) et de consultants transformation digitale ETI. Si vous vous reconnaissez dans un de ces profils, contactez-nous directement.

5. Contribution open source. Nous souhaitons contribuer davantage : templates LangGraph pour des patterns d'agents courants, plugins Payload CMS pour les besoins ETI (conformité RGPD, gestion de workflows d'approbation), starters Next.js 16 pour les projets B2B. Nos évaluations de dette technique et nos patterns d'architecture pourraient également être publiés en open source.

---

#Un message personnel de Foued

Ce qui me motive en 2026 peut se résumer en une observation.

Depuis quelque temps, je vois des ETI françaises — des entreprises qui créent de l'emploi, qui exportent, qui ont des savoir-faire uniques — accéder à des capacités de transformation digitale qui étaient réservées aux grandes entreprises. Non pas parce que les ETI sont devenues plus riches, mais parce que les coûts de développement et de déploiement ont baissé grâce à l'IA dans notre process.

Ça ne veut pas dire que c'est simple. Une migration Oracle Forms reste une migration Oracle Forms — avec sa complexité métier, ses données à qualifier, son change management. Un agent IA en production requiert une architecture sérieuse, des guardrails, du monitoring.

Mais le seuil d'entrée a fondamentalement changé : des projets qui demandaient des budgets et des délais hors de portée il y a quelques années deviennent accessibles. C'est structurant pour une ETI.

Ce que j'observe aussi, et qui m'inquiète un peu : la fenêtre de différenciation compétitive que ces transformations ouvrent est temporaire. Les ETI qui se transforment maintenant prennent une avance sur leurs concurrents. Dans quelques années, les outils seront encore plus accessibles et tout le monde rattrapera son retard. L'avantage appartient à ceux qui bougent maintenant, pas à ceux qui attendent que tout soit parfaitement mature.

Si vous êtes dirigeant d'une ETI et que vous avez le sentiment d'avoir un sujet de transformation sur lequel vous n'avez pas encore trouvé le bon partenaire — quelqu'un qui parle à la fois transformation métier et ingénierie sérieuse, sans vous vendre un projet plus gros que nécessaire — je suis disponible pour un échange direct.

Mon email : foued@nehos-groupe.com. Pas de formulaire de contact, pas d'assistant — moi directement.

Photos : Mikhail Nilov, RDNE Stock project sur Pexels.