Le réflexe habituel consiste à passer par des pilotes externes comme ODBC ou OleDB. Ces solutions, souvent gratuites et encore utilisées, ont longtemps rendu service. On retrouve aussi DB2 Connect, solution d’IBM plus complète mais coûteuse et contraignante à mettre en place. Toutes reposent néanmoins sur du code natif compilé pour chaque architecture, et fonctionnent en dehors de la CLR (.NET Common Language Runtime, le moteur d’exécution standard de .NET). Résultat : une intégration incomplète dans l’écosystème .NET, limitée à la base de données, avec des dépendances propres à chaque environnement et une portabilité réduite des applications.
NTi apporte une approche différente, résolument moderne. Intégralement basé sur la CLR .NET, il est multiplateforme (Windows, Linux, macOS) et ne nécessite aucune dépendance externe. Aucune installation n’est nécessaire côté IBM i, tout s’exécute dans l’environnement .NET, comme n’importe quel autre provider.
L’accès ne se limite donc plus à DB2 for i : vous pouvez exécuter des commandes CL, appeler des programmes RPG, et plus généralement, accéder à l’ensemble des ressources IBM i avec une syntaxe .NET standard. À ce jour, vous ne trouverez aucun équivalent sur le marché, offrant ce niveau d’intégration entre .NET et l'IBM i.
Connexion.
En pratique, la connexion à l’IBM i se fait comme avec n’importe quel autre SGBD supporté par .NET. La différence essentielle étant qu’il s’agit d’un provider ADO .NET dédié à l’IBM i, AS/400, iSeries, pensé et optimisé pour DB2 for i. Autrement dit, le principe est exactement le même que pour les autres bases de données:
- Pour SQL Server, on utilise
SqlConnection. - Pour PostgreSQL, on utilise
NpgsqlConnection. - Pour l'IBM i, on utilise
NTiConnection.
Le code est identique dans sa structure, qu’il s’agisse d’ouvrir une connexion ou d’exécuter une commande SQL. La seule différence se trouve dans la classe employée et la chaîne de connexion, tout le reste reposant sur le modèle standardisé ADO.NET.
Installer les packages NuGet.
Dans Visual Studio, ouvrez la console et installez:
Install-Package Aumerial.Data.NTiConnexion de base.
using Aumerial.Data.Nti;
using var conn = new NTiConnection("server=myIBMi;user=myUser;password=myPassword;");
conn.Open();
try
{
conn.ExecuteClCommand("CRTLIB LIB(MYLIB) TEXT('new library')");
}
catch(NTiException ex)
{
Console.WriteLine(ex.Message);
}
conn.Close();
Si vous connaissez
SqlConnection, vous connaissez déjà NTi. Vous avez ainsi la garantie d’une prise en main immédiate pour toute équipe ayant déjà la compétence .NET, sans besoin de compétences spécifiques IBM i.
Nouveautés et propriétés de connexion.
NTi a évolué dans ses dernières versions pour répondre aux besoins de performance et de sécurité des applications modernes, mais aussi aux attentes formulées par nos clients. Ces fonctionnalités s’activent directement dans la chaîne de connexion, au même titre que les paramètres classiques server, user et password.
Depuis la version 3.2.3, un pool de connexion est disponible, et activé par défaut. Concrètement, les sessions IBM i sont réutilisées au lieu de recréer un job (QZDASOINIT) à chaque requête, réduisant drastiquement les temps de réponse et améliorant la tenue en charge des applications, notamment avec Entity Framework Core.
La sécurité a également été renforcée avec la prise en charge de l'authentification multi-facteur (MFA) à partir de la version 4.4.0. NTi s'appuie sur le mécanisme TOTP introduit par IBM dans la version V7R6 de son OS. Un code à usage unique peut être transmis directement dans la chaîne de connexion ou récupéré via un callback, permettant d'intégrer facilement le MFA dans les applications .NET déjà existantes.
Un sujet d’ailleurs au cœur de l’actualité : il a encore été largement discuté lors de l’événement Securit.i édition 2025, rendez-vous de référence sur la sécurité IBM i, où les nouveautés V7R6 et le MFA tenaient une place centrale. Avec NTi, cette évolution est déjà disponible et opérationnelle dans vos projets .NET.
À noter également que NTi établit la connexion à l’IBM i via des canaux TCP/IP standards, en s’appuyant sur les services habituels du système:
- QZDASOINIT pour la base de données
- QZRCSRVS pour les programmes et les commandes
- QZSOSIGN pour le Signon
Il est possible d'activer une connexion chiffrée SSL/TLS par simple paramètre dans la chaîne de connexion, garantissant que les échanges entre l'applicatif .NET et l'IBM i restent protégés. La configuration SSL doit évidemment être réalisée en amont pour pouvoir établir ce type de connexion.
Entity Framework Core avec NTi
Entity Framework Core (EF Core) est le framework officiel de Microsoft pour l’accès aux données dans .NET. Il fournit une couche d’abstraction qui permet de manipuler les données directement via du code C# (LINQ), sans écrire de SQL explicite.
Avec l'extension EF Core disponible avec NTi, vous bénéficiez de cette approche standard mais dédiée à DB2 for i. Votre logique métier reste entièrement en C#, et les requêtes SQL sont générées automatiquement vers l’IBM i. Deux approches possibles, selon vos besoins:
- Database First (DB First): à partir des tables et schémas existants sur DB2 for i, vous générez directement vos entités C#. C'est la solution idéale pour moderniser une base déjà en production sans perturber les équipes métier.
- Code First: vous définissez vos entités directement en C#, et EF Core crée la structure correspondante dans DB2 for i, avec le mappage automatique des bons types. Idéal pour les nouveaux projets.
Toutes les opérations classiques sont couvertes: création, lecture, Mise à jour et suppression (CRUD) mais aussi jointures, agrégations, pagination ou requêtes paramétrées. Le développeur .NET reste dans un cadre homogène, sans avoir à se préoccuper des spécificités de DB2 for i.
Exemple:
var ctx = new ProductDbContext();
string filter = "PROD";
var data = ctx.Products
.Where(p => p.Label.Contains(filter))
.Select(p => p.Label.Trim())
.ToList();Génère automatiquement côté IBM i:
SELECT TRIM(p.Label)
FROM Products AS p
WHERE POSITION(@__filter_0, p.Label) <> 0La dernière version de l'extension va plus loin en ajoutant un mapping précis des fonctions scalaires natives DB2 for i. Concrètement, lorsqu’un développeur utilise des méthodes courantes en C# (chaînes, nombres, etc.), elles sont traduites en instructions SQL typées "DB2 for i". Les calculs et transformations ne sont donc plus simulés côté .NET, mais exécutés par DB2 lui-même sur l'IBM i. Et comme il est conçu pour encaisser et traiter de fortes charges en toute fiabilité, c'est le meilleur endroit pour y déléguer ces opérations afin de garantir des résultats précis et des performances optimales.
Conclusion.
On ne bâtit pas l’avenir avec des outils du passé. Les pilotes historiques vous ont sûrement longtemps accompagnés, mais montrent aujourd'hui clairement leurs limites dès que l'on parle d'évolution, de cloud, conteneur ou portabilité. S'appuyer encore dessus, c'est faire le choix d'une dette technique croissante, et repousser les problèmes à demain.
Avec NTi, changez de perspective: optez pour un connecteur .NET natif, stable et sécurisé, conçu et pensé pour s’intégrer naturellement dans vos projets .NET/IBM i sur le long terme.
Alors, si la question reste — Comment connecter votre IBM i (AS/400) à .NET ? — la réponse est désormais évidente: non pas avec des rustines logicielles, mais avec ce qui se fait de mieux actuellement sur le marché. Et la meilleure façon de s'en convaincre reste encore de l’essayer.
Demandez dès aujourd’hui votre licence d’essai NTi et mesurez par vous-même la différence.
Quentin Destrade