Agence IA pour CTO — Architecture qui tient, LLMs en production
Nehos est une équipe d'ingénieurs et d'architectes dont la partie technique est pilotée par Chokri Siala (CTO, architecture système). On livre des agents IA conçus pour tourner en production, avec une stack souveraine possible et une architecture sans dette technique cachée.
Nos clients types
Le coût d'infrastructure. Le coût d'un serveur GPU en location (tarif variable selon la configuration, à vérifier chez l'hébergeur). Qualité de réponse : Mistral Large 2 est comparable à GPT-4o sur les tâches français-centric (langue, droit français, contexte culturel). Sur les tâches de code complexe multi-step, GPT-4o ou Claude 3.5 Sonnet gardent une légère avance.
Les contraintes SecNumCloud. OVHcloud SecNumCloud impose un périmètre géographique et technique strict. Bon côté : qualification ANSSI, idéal pour les données sensibles, les clients institutionnels et les marchés publics. Mauvais côté : le catalogue de services managés est moins riche qu'AWS ou Azure (pas de services ML managés comme SageMaker ou Azure ML), les temps de provisionnement sont plus longs, certains services tiers incompatibles.
La solution Nehos : architecture hybride avec routage automatique. On ne choisit pas entre souveraineté et performance — on achemine automatiquement selon la sensibilité des données. Architecture cible : (1) classification automatique des requêtes selon sensibilité (données personnelles, données contractuelles, données publiques), (2) routage vers Mistral Large 2 auto-hébergé OVH SecNumCloud pour les données sensibles, (3) routage vers OpenAI GPT-4o ou Anthropic Claude 3.5 pour les données non sensibles où la qualité prime, (4) couche de cache Redis pour les requêtes répétitives (économie sur le coût des tokens), (5) fallback automatique entre modèles en cas d'indisponibilité. Ce pattern répond aux exigences SecNumCloud tout en maintenant la performance sur les usages non sensibles.
#Défi 4 — Build vs Buy IA : le framework de décision
C'est peut-être la décision stratégique la plus sous-estimée des CTOs en 2026. On voit des ETI qui self-host Llama 3.1 pour des usages qui ne le justifient pas, et des ETI qui utilisent des no-code IA pour des cas critiques qui demanderaient du custom.
Le framework de décision Nehos (matrice sur 4 critères). Pour chaque cas d'usage IA, on évalue : (1) Sensibilité des données (faible / moyenne / haute / critique), (2) Niveau de personnalisation requis (générique / adapté / très spécifique / propriétaire), (3) Volume et coût TCO (faible volume / moyen / élevé / très élevé), (4) Compétences équipe disponibles (nulle / basique / intermédiaire / avancée).
No-code IA (n8n, Make, Zapier + LLM) : recommandé quand sensibilité faible, personnalisation générique, volume faible, et équipes sans compétence dev. Cas typique : automatisation email, génération de résumés internes, workflows de classification simples. Limite : pas scalable, pas testable, pas maintenable à l'échelle.
APIs LLM managées (OpenAI, Anthropic, Mistral API) : recommandé quand sensibilité faible à moyenne, personnalisation par prompt engineering, volume moyen, équipe dev présente. Cas typique : chatbot support, génération de contenu, assistant interne. Avantage : time-to-market rapide, modèles à l'état de l'art. Inconvénient : coût variable, dépendance fournisseur, données transmises à un tiers.
Self-hosting LLM (Mistral, Llama sur OVHcloud) : recommandé quand sensibilité haute à critique (données clients, données contractuelles, données santé), personnalisation par fine-tuning, volume élevé (économie coût tokens), exigence souveraineté (marchés publics, ETI réglementées). Coût d'infrastructure à amortir sur la durée pour être rentable face à l'API.
Développement from scratch (custom ML) : recommandé uniquement quand les use cases sont ultra-spécifiques au domaine métier, que les données d'entraînement propriétaires sont suffisantes (100k+ exemples labellisés), et que la compétitivité dépend d'une capacité IA unique. Rare dans le contexte ETI — ne justifie que pour des acteurs dont l'IA est le cœur de valeur.
→ Prêt à passer à l’action ? Réservez un appel découverte de 15 minutes avec notre équipe pour analyser votre projet — sans engagement.
#La stack technique Nehos — et pourquoi chaque choix
On ne livre pas une stack par défaut. On adapte selon le contexte. Mais voici notre stack validée en production 2025-2026, avec les justifications architecturales que vous attendez en tant que CTO.
Next.js 16 App Router + TypeScript (strict mode). Les React Server Components permettent de réduire fortement le JavaScript client sur les pages de contenu — critique pour la performance perçue. Le Partial Pre-Rendering (PPR) combine rendu statique et dynamique dans une même page sans compromettre le Time to First Byte.
TypeScript strict mode n'est pas négociable : on valide les outputs LLM avec Zod avant qu'ils n'entrent dans l'UI — c'est la seule façon de gérer les sorties non structurées de façon fiable.
Payload CMS (self-hosted). CMS headless type-safe en TypeScript, configuration code-first, hébergeable sur votre propre infrastructure. Pas de vendor lock-in SaaS (contrairement à Contentful ou Sanity). La définition des collections Payload génère automatiquement les types TypeScript — zéro désynchronisation entre CMS et frontend. Migration vers n'importe quel autre CMS possible sans réarchitecturer le frontend.
Couche LLM — trois modèles pour trois usages. Mistral Large 2 est notre défaut pour les données sensibles : contexte 128k, performances françaises excellentes, self-hostable sur OVHcloud GPU, fine-tunable. GPT-4o reste notre choix pour les cas non sensibles où la qualité de raisonnement prime — code generation, analyse de documents complexes en anglais, tâches multi-step avancées.
Llama 3.1 70B (ou 405B pour les cas critiques) est réservé aux cas de fine-tuning sur données métier spécifiques : quand votre domaine est si particulier (terminologie, raisonnement spécifique) qu'un modèle généraliste performe mal même avec du prompt engineering avancé.
Vector DB — Qdrant self-hosted. Qdrant est l'unique base vectorielle qu'on recommande en self-hosted pour production 2026. Raisons : index HNSW avec paramétrage fin (ef_construct, m), filtrage combiné vecteur + payload sans dégradation de performance, quantisation scalaire pour réduire l'empreinte mémoire de 4x sur les gros corpus, API REST + gRPC, client Python et TypeScript matures. On évalue Weaviate et Milvus régulièrement — Qdrant reste notre standard sur les benchmarks en conditions réelles.
Orchestration LLM — vanilla Python préféré à LangChain. LangChain résout de vrais problèmes mais crée des abstractions qui compliquent le debug en production. Notre règle : on utilise LangChain si son apport est net et documenté sur le cas d'usage spécifique. Dans tous les autres cas, on préfère une orchestration custom en Python pur + httpx + Pydantic pour la validation — plus verbose mais plus maintenable, plus debuggable, moins de dépendances à gérer lors des mises à jour. Pour les workflows multi-agents complexes, on évalue LangGraph et Temporal selon le besoin.
Observabilité LLM — Langfuse + Grafana. Langfuse est open source, self-hostable, et donne exactement ce dont un CTO a besoin pour piloter les LLMs en production : coût par token et par session, latence par modèle, taux d'erreur, distribution des scores de qualité (human feedback), tracing complet des chaînes d'appels.
On complète avec Grafana pour les métriques infrastructure (GPU usage, mémoire, API latency at p50/p95/p99). Cette combinaison remplace avantageusement les outils propriétaires comme Helicone ou Weights & Biases pour les CTOs qui veulent conserver la maîtrise de leurs données d'observabilité.
Infrastructure — hybride OVHcloud + Netlify. Un hébergeur qualifié SecNumCloud (OVHcloud par exemple) pour tout ce qui est donnée sensible, modèles self-hosted, bases de données. Netlify pour le frontend Next.js (Edge Network, déploiements atomiques, preview URLs par PR — workflow de développement imbattable). Cette séparation est délibérée : on tire les forces de chaque plateforme sans mélanger les workloads.
CI/CD — GitHub Actions + Playwright + Vitest + Storybook. Pipeline standardisé Nehos : lint + type-check à chaque push (30 secondes), tests unitaires Vitest sur chaque PR (1-3 minutes), tests E2E Playwright sur preview Netlify avant merge (5-15 minutes selon scope), tests d'intégration LLM (prompts de regression) sur merge main.
Storybook déployé automatiquement pour la documentation des composants. Un seuil minimal de couverture est imposé dans le pipeline — le merge est bloqué en dessous.
#Ce que Nehos livre — et ce qui reste dans votre codebase
Propriété du code à 100 %. Aucun framework propriétaire Nehos dans votre codebase. Tout ce qu'on développe — agents IA, configurations CMS, composants UI, pipelines data — vous appartient et peut être maintenu par n'importe quelle équipe tech compétente. Pas de clause de reversibilité, pas de licence propriétaire, pas de dépendance à des outils Nehos internes.
Documentation obligatoire, pas optionnelle. On documente le code pendant qu'on l'écrit, pas à la fin du projet. Architecture Decision Records (ADRs) rédigés pour chaque décision importante (choix de stack, pattern d'architecture, compromis acceptés). README technique maintenu sprint par sprint.
Diagrammes d'architecture à jour dans le repo. Runbooks opérationnels pour les agents IA en production. Si la documentation est absente au moment de la livraison, le sprint n'est pas validé.
Processus de revue d'architecture. Chokri Siala ou un architecte sénior Nehos revoit chaque proposition technique avant livraison. On n'est pas des yes-men : si une décision client est techniquement mauvaise, on le dit avec les arguments. Un CTO n'a pas besoin qu'on valide ses mauvaises idées — il a besoin d'un partenaire qui push back sur ce qui ne tiendra pas en production.
Protocole de transfert de compétences. En fin de mission, on organise des sessions de transfert technique avec les équipes internes (architecture, opérations, développement). L'objectif : que votre équipe soit capable de maintenir et faire évoluer le système sans Nehos après la mission principale. On vérifie ce point et on ajuste le protocole si nécessaire.
#Collaboration CTO × Nehos : comment ça se passe concrètement
Avant de démarrer — revue d'architecture. Avant toute proposition chiffrée, Chokri ou un architecte sénior Nehos réalise un audit technique de votre contexte : codebase existante, architecture actuelle, dette technique identifiée, ambitions IA. Output : diagnostic écrit avec recommandations priorisées et premières estimations d'effort.
Ce temps est facturé (audit IA express d'une journée à 990 € HT, déduit du projet s'il est lancé dans les trois mois) mais non engageant — vous pouvez vous arrêter là avec le document et le faire faire par quelqu'un d'autre.
Semaine 1 — cadrage technique et setup. Définition des ADRs initiaux (choix de stack, patterns), setup de l'environnement de développement partagé (repo GitHub, CI/CD, environnements dev/staging/prod), intégration du cycle de travail Nehos dans votre process (rituel de sprint, code review, communication async). Un CTO de notre côté (Chokri ou un lead architect) est en contact direct avec vous — pas de chef de projet intermédiaire.
Pendant la mission — sprints de 2 semaines. Chaque sprint démarre par un planning (remote ou présentiel) et se termine par une démo fonctionnelle du livrable. Toutes les décisions techniques importantes sont documentées dans des ADRs validés par votre équipe. Code review systématique avec vos développeurs si votre équipe interne est impliquée. Rétrospectives techniques bimensuelles pour identifier et corriger les dérives.
Communication async + sync. Canal Slack ou Teams dédié, réponse aux questions techniques dans des délais courts convenus au démarrage. Les PRs GitHub sont ouvertes et documentées pour permettre le suivi. Pas de black box : vous avez accès en lecture à tout — monitoring, logs, pipeline CI/CD, dashboards Langfuse. Réunions sync réduites au nécessaire — on assume que votre temps est précieux.
Mode renfort d'équipe (staff augmentation). Pour les CTOs qui ont une équipe interne mais manquent de compétences IA/LLM séniors, on intervient en mode renfort. Nos ingénieurs IA s'intègrent dans votre équipe, utilisent vos process (GitHub, Jira, rituel agile), et montent en compétences vos développeurs par le biais de pair programming et de code review. Objectif : que votre équipe puisse gérer seule à terme. Tarif renfort en régie : à partir de 275 € HT par jour.
Questions & réponses
Questions techniques fréquentes — CTO et directeurs techniques
Quatre mécanismes non-négociables. (1) Un seuil minimal de couverture de tests imposé dans la CI/CD — le merge est bloqué en dessous. (2) Architecture Decision Records (ADRs) rédigés pour chaque décision technique importante, validés par Chokri ou un lead architect avant implémentation. (3) Code review systématique : chaque PR passe par au moins un ingénieur Nehos sénior avant merge. (4) Documentation technique maintenue sprint par sprint — README, diagrammes d'architecture, runbooks opérationnels. Si un livrable n'atteint pas le standard convenu, on le reprend avant de le valider.
Oui — on adapte selon votre contexte, on n'impose pas notre stack. La revue d'architecture initiale vise précisément à comprendre ce que vous avez et à identifier ce qu'il faut changer ou conserver. Nous savons intervenir sur des infrastructures AWS, Azure, GCP, OVHcloud et on-premise. Si votre hébergement actuel est raisonnable et que le coût de migration ne se justifie pas, on garde ce que vous avez. Si au contraire il bloque les objectifs IA (GPU pour LLM self-hosted, observabilité, souveraineté), on vous propose une migration argumentée avec chiffrage ROI.
C'est une préoccupation légitime et on la partage. Notre règle architecturale : abstraire la couche LLM derrière une interface commune dès le sprint 1. Concrètement : une interface LLMProvider avec les méthodes standardisées (complete, stream, embed), des implémentations spécifiques pour chaque fournisseur (OpenAI, Mistral, Anthropic, Ollama), un routeur qui sélectionne le modèle selon les critères définis (sensibilité, coût, latence). Changer de LLM principal = changer une ligne de config, pas refactoriser 50 fichiers. On livre systématiquement cette architecture avec les tests qui prouvent que le swap fonctionne.
Le transfert n'est pas un bonus de fin de projet — il est planifié dès le sprint 1. Format standard Nehos : (1) Pair programming régulier entre ingénieurs Nehos et vos développeurs sur les sujets IA/LLM (selon l'appétit de l'équipe), (2) Documentation interne rédigée pendant le développement (pas après), (3) Sessions dédiées en fin de projet sur les sujets critiques (architecture agents IA, opérations Langfuse, gestion des modèles). Objectif : que votre équipe puisse faire évoluer le système sans nous appeler après la mission. On vérifie ce point en fin de projet.
On modélise les coûts à plusieurs horizons (volume actuel, x10, x100) dès le début de chaque projet. Les leviers qu'on active systématiquement : (1) cache sémantique Redis sur les requêtes similaires (économie sur les usages répétitifs), (2) routage multi-modèles — modèles plus petits/moins chers pour les tâches simples, modèles séniors pour les tâches complexes, (3) compression de context window (résumé des historiques longs, chunking optimisé pour RAG), (4) batch processing quand la latence n'est pas critique, (5) migration vers self-hosted au-delà d'un seuil de rentabilité calculé.
Oui — c'est même une modalité qu'on préfère dans certains cas, notamment quand le CTO a une équipe solide mais sans expertise LLM/agents IA. Mode opératoire : nos ingénieurs IA s'intègrent dans votre équipe (GitHub, Jira ou Linear, rituel agile existant), participent aux planning et rétrospectives, font des code reviews de la codebase IA. Tarif en régie : à partir de 275 € HT par jour. Un engagement de quelques mois est conseillé pour que l'intégration soit utile. L'objectif n'est pas de créer une dépendance — c'est de monter votre équipe en compétences sur la durée puis de réduire progressivement notre présence.
Parlons de votre projet
Un devis chiffré, sans engagement
Décrivez votre besoin en deux minutes : un consultant senior vous répond avec une première estimation et les prochaines étapes.
- Réponse sous 24 h ouvrées
- Sans engagement
- Un consultant senior vous répond