// NIJITECH · TECHNOLOGIE CŒUR
L'orchestration de modèles, c'est le vrai travail pour amener l'IA en production — pas seulement envoyer une requête à un modèle. Le vrai travail consiste à décider quel modèle s'exécute, à vérifier la sortie et à pouvoir montrer d'où vient le résultat. niji core est le nom de cette couche.
niji core est l'épine dorsale d'IA commune sur laquelle tournent les produits nijitech et les solutions clients. Elle convertit l'entrée en une représentation commune, décide quel modèle s'exécute selon le type de tâche (orchestration de modèles), vérifie la sortie produite et la relie à sa source. Les données sont traitées dans la région Union européenne ; les décisions critiques passent par une validation humaine.
00 — LE CONCEPT
L'orchestration de modèles, c'est la gestion de plusieurs modèles d'IA sur un même pipeline. Le système décide quel modèle s'exécute selon le type d'entrée et les exigences de la tâche, traite le résultat et produit une sortie cohérente.
Ranger un texte dans l'une de deux catégories et mener une analyse en plusieurs étapes ne demandent pas la même capacité. Mettre le modèle le plus puissant sur chaque tâche, c'est louer une pelleteuse pour planter un clou : ça marche, mais le coût n'a aucun sens.
Le coût d'un appel de modèle est faible par transaction, mais il se multiplie avec le volume. Dans un système qui fait dix mille appels par jour, router la moitié des tâches vers un modèle plus petit se traduit par une facture nettement plus basse et une latence nettement réduite.
Un système bâti sur un seul fournisseur de modèles reste exposé à ses changements de prix, à ses limites de quota et à ses mises à jour de politique. La couche d'orchestration desserre ce lien : le modèle change, le pipeline reste.
Le meilleur modèle du jour peut être deuxième dans six mois. Changer un appel de modèle enfoui dans le code applicatif est à chaque fois un travail de développement ; le même changement dans la couche de routage est un travail de configuration.
01 — COMMENT ÇA MARCHE
Le pipeline s'exécute dans le même ordre dans chaque produit ; ce qui change, c'est ce qu'est l'entrée et ce que devient la sortie.
Audio, texte et signaux système — trois formats, un seul flux.
L'audio d'une réunion, le message WhatsApp d'un client et un flux de prix de marketplace n'ont rien en commun. La couche d'entrée les convertit en une représentation partagée : l'audio devient du texte, le texte libre est structuré, les signaux système s'alignent avec un horodatage. Les couches suivantes n'ont pas besoin de savoir d'où vient quoi.
Quelle tâche va à quel modèle — le système décide.
Envoyer chaque tâche au modèle le plus puissant coûte cher ; les envoyer toutes au moins cher produit de mauvaises réponses. La couche de routage regarde le type et les exigences de la tâche et décide quel modèle s'exécute. Un petit modèle suffit pour une classification courte, tandis qu'un modèle plus capable prend le relais pour un raisonnement en plusieurs étapes. Cette décision n'est pas figée : elle évolue avec les résultats de mesure.
La sortie du modèle n'est jamais utilisée brute : elle passe d'abord un contrôle.
Le modèle produit un résultat, mais ce résultat n'arrive pas brut à l'utilisateur. La sortie correspond-elle au format attendu, est-elle cohérente avec sa source, dépasse-t-elle le seuil de confiance : tout cela est vérifié. Une sortie sous le seuil est soit régénérée, soit envoyée en validation humaine. La vraie défense contre l'hallucination se trouve dans cette couche.
Un résumé, un score, un appariement — et la source de chacun.
La sortie dépend du produit : un résumé de réunion, un score de rentabilité, un appariement de chauffeur. Ce qui ne change pas, c'est que chaque sortie est reliée à sa source. De quelle phrase vient un résumé, de quelles données découle un score — tout est consigné. Sans ce lien, ni audit ni contestation ne sont possibles.
02 — QUATRE PRINCIPES
Les quatre sont des choix ; chacun a un coût et une raison. Nous avons écrit les deux ci-dessous.
Dans une installation on-premise, les données restent dans votre propre infrastructure et n'en sortent pas. En usage cloud, le traitement a lieu dans les régions États-Unis et UE ; les garanties de l'art. 9 de la KVKK s'appliquent aux transferts hors frontières. La liste complète des sous-traitants figure à l'annexe C de l'avenant relatif au traitement des données.
L'article 9 de la loi turque sur la protection des données (KVKK) soumet les transferts transfrontaliers au consentement et à des garanties ; le RGPD traite la résidence des données comme une condition de base de l'auditabilité. Une installation on-premise satisfait les deux sans ouvrir le moindre débat sur les transferts : les données ne quittent jamais l'organisation. En usage cloud, le traitement a lieu dans les régions États-Unis et UE et les garanties de l'article 9 s'appliquent au transfert.
Les appels de modèle passent par une infrastructure située on-premise ou dans le cloud. Quand le service juridique de l'acheteur demande « où vont les données », la réponse tient en une phrase.
Chaque résultat est relié à la source dont il provient.
On ne peut pas contester une sortie en boîte noire. Si vous ne pouvez pas montrer pourquoi le résultat est ce qu'il est, vous ne pouvez ni le déboguer ni l'auditer, et l'utilisateur ne fera pas confiance au système. L'explicabilité est un choix d'architecture, pas une fonction de reporting.
Chaque élément d'un résumé de réunion remonte à une phrase de la transcription, un score produit aux données de demande et de concurrence qui le sous-tendent, un déplacement de budget au changement de performance qui l'a déclenché.
Les décisions critiques passent par une validation humaine avant de sortir.
Les décisions entièrement autonomes ont du sens quand le coût d'une erreur est faible. Pour des actions coûteuses à annuler — émettre une facture, envoyer une réponse client, déplacer du budget —, l'étape de validation n'est pas une faiblesse du système mais sa garantie.
Quelles décisions exigent une validation se fixe à la conception — un seuil prévu dès le départ, pas un contrôle rajouté après coup.
Le traitement s'exécute au plus près de l'utilisateur.
Dans un système temps réel, la latence compte autant que la précision. Un résumé qui arrive pendant que la réunion se poursuit devient inutile avec deux secondes de retard. Chaque requête qui voyage vers une région lointaine et revient entame ce budget.
Les opérations légères s'exécutent près de l'utilisateur ; l'inférence lourde reste à la couche centrale. Ce partage réduit à la fois la latence et le coût.
03 — CONFORMITÉ ENTREPRISE
La conformité est un travail d'architecture, pas de paperasse. Le tableau ci-dessous montre quelle exigence légale est satisfaite par quelle décision de conception.
| Exigence | Fondement | Réponse d'architecture |
|---|---|---|
| Les données ne doivent pas quitter le pays | KVKK art. 9 | Le traitement a lieu on-premise ou dans le cloud. |
| Les décisions automatisées doivent pouvoir être contestées | RGPD art. 22 | Validation humaine sur les décisions critiques ; chaque sortie reliée à sa source. |
| Le traitement doit être auditable | KVKK art. 12 · RGPD art. 30 | La chaîne entrée, décision de routage et sortie est journalisée et traçable. |
| Minimisation des données | KVKK art. 4 · RGPD art. 5 | Les durées de conservation sont définies au contrat ; le stockage indéfini n'est pas le comportement par défaut. |
| Les données ne doivent pas servir à d'autres fins | Limitation des finalités | Non par défaut. Deux exceptions : dans les travaux de preuve de concept, lorsque l'entreprise participante a donné son accord écrit ; et pour le développement de la plateforme propre d'un client, à la demande de ce client. En dehors de ces cas, les données client ne servent pas à l'entraînement des modèles, et un modèle entraîné sur les données d'un client n'en sert pas un autre. |
04 — CE QUI TOURNE DESSUS
On ne sait si une architecture tient qu'en l'éprouvant sur des problèmes différents. Les seize produits ci-dessous font des choses très différentes, et pourtant ils tournent sur le même pipeline.
nijibotAudio → transcription → résumé → action
WhatsModPlusieurs canaux → une boîte → réponse validée
AMZAIPlusFiche → prix → Buy Box
Amz CalculusDemande + concurrence + coût → rentabilité
cep taxiPosition + demande → appariement → paiement
OtoWosÉchelonnement + séquestre + archive légale
AdMostPerformance → répartition du budget → ROAS
PylunChaîne compatible EVM + couche DeFi
CMDeskAccès à distance → SSH → déploiement en masse
KovanlyMachines virtuelles → réseau → sauvegarde
LattixRéseau pair-à-pair → chiffrement de bout en bout
HiriVivier de candidats → notation → validation humaine
Global Company ServiceDocuments → constitution → banque et immatriculation fiscale
Tera LIVEDirect → salon vocal → économie de cadeaux
Exporia.ioCatalogue → liste d'acheteurs → séquence commerciale
Yeşil DünyaMesure → attribution à la source → suivi de réductionTERMES
Plutôt que de répéter les définitions ici, nous les gardons à un seul endroit dans le glossaire.
QUESTIONS FRÉQUENTES
niji core est l'épine dorsale d'IA commune sur laquelle tournent les produits nijitech et les solutions clients. Elle reçoit l'entrée, décide quel modèle s'exécute, vérifie la sortie et la relie à sa source. Tous les produits utilisent le même cœur.
En pratique, les deux décrivent la même idée : gérer plusieurs modèles sur un même pipeline. « Orchestration de modèles » met l'accent sur la décision du modèle qui s'exécute ; « orchestration d'IA » met l'accent sur l'ensemble des modèles, outils et flux de données. niji core couvre les deux couches.
Nous ne sommes pas liés à un modèle unique. Selon le type de tâche, différents modèles interviennent, et ce choix peut évoluer avec les résultats de mesure. L'indépendance vis-à-vis des modèles est une décision délibérée : une architecture dépendante d'un seul fournisseur reste exposée à ses changements de prix et de politique.
La défense est à trois couches. La sortie est contrôlée par rapport au format attendu ; sa cohérence avec la source est vérifiée ; les résultats sous le seuil de confiance sont soit régénérés, soit envoyés en validation humaine. À cela s'ajoute que relier chaque sortie à une source rend visible un résultat inventé.
L'approche par défaut est la recherche, pas l'entraînement : nous laissons le modèle atteindre vos données au moment de la requête (RAG). Comme les données ne sont pas cuites dans le modèle, elles restent à jour et il reste possible de les retirer. Les cas qui nécessitent réellement un entraînement sur mesure sont évalués séparément.
La précision se mesure par tâche, et chaque projet construit son propre jeu d'évaluation. Une affirmation figée « x pour cent de précision » n'a aucun sens si l'on ne dit pas sur quelle tâche et sur quelles données elle a été mesurée. Nous convenons ensemble de la métrique pendant le cadrage.
C'est précisément le rôle de la couche d'intégration. Nous construisons des connexions opérationnelles vers les agendas, CRM, messageries et systèmes comptables. À quel système vous vous connectez — et si c'est techniquement possible — devient clair pendant le cadrage.
Pour les questions générales, voir la page FAQ · pour nos services, voir solutions entreprise
COMMENCER
Lors d'un appel de cadrage, nous déterminons ensemble lequel de vos travaux correspond à ce pipeline.
Réserver un appel de cadrage →Nous souhaitons utiliser Google Analytics pour comprendre comment le site est utilisé. Cet outil dépose des cookies et transfère des données vers les États-Unis. Si vous refusez, le site fonctionne exactement de la même façon.
