Architecture IBM i : pourquoi ce système n’a (presque) jamais eu de virus
Je causais tranquillement avec Copilot de la prochaine disponibilité de Windows 12 (ou autre) et de l’éventuelle refonte du noyau. On parle souvent de « nouvelle technologie » à propos des applis sous Windows ou Linux, en oubliant que Windows NT, à la base des Windows actuels, date de 1995, et que Linux, sorti en 1991, hérite de l’Unix de 1970. Alors, je veux bien qu’on se moque des « vieux écrans verts », mais la paille et la poutre, ça vous cause ?
Il est amusant de voir que l’IA de Microsoft reconnaît elle-même l’aspect révolutionnaire de l’OS et que bon nombre de ses idées auraient pu être reprises ailleurs.
Une réserve toutefois, sur la sécurité en tant que sujet complet : les attaques par ingénierie sociale ne sont pas neutralisées par l’IBM i elles sont seulement limitées par le fait qu’en standard un utilisateur n’a droit qu’à trois tentatives de connexion (comme le code PIN d’un téléphone) avant blocage de son profil. Il ne faut jamais négliger cet aspect. J’ai vu bon nombre d’entreprises qui laissaient leur serveur IBM i sans sécurité sous prétexte que le système est « blindé »… non, c’est devenu une négligence inacceptable de nos jours. Notre équipe accompagne d’ailleurs régulièrement des clients sur ces sujets dans le cadre de nos missions de cybersécurité.
Voici donc la discussion, condensée pour éviter les redites de Copilot.
Le modèle objet pur d’IBM i
IBM i (ex-AS/400, OS/400) n’est pas qu’un OS : c’est une architecture pensée dès le départ autour d’un modèle objet.
- Tout est un objet : fichiers, programmes, librairies, devices, jobs, chacun typé, sécurisé, persistant par nature.
- Single-level store : une mémoire unifiée où la distinction RAM/disque n’existe pas. Pas de chemins façon /usr/bin ou C:\Windows, pas de fragmentation, pas de corruption liée à la séparation mémoire/stockage. Ce concept de stockage à niveau unique, théorisé dès les années 1970, reste l’une des signatures les plus distinctives de la plateforme.
- Pas de DLL, pas d’EXE, pas de drivers à la Windows : les objets système sont contrôlés, pas chargés dynamiquement comme des modules externes.
- DB2 intégrée au noyau : le système est une base de données. Pas de mismatch entre OS et SGBD, pas d’ORM à gérer pour la cohérence des données.
Frank Soltis a conçu un système orienté objet avant Java, avec mémoire unifiée avant les SSD, virtualisation native avant VMware, et sécurité intégrée avant SELinux, une architecture RISC avant que ce soit à la mode. Steve Will a fait évoluer le tout sans jamais trahir cette philosophie.
Pourquoi ce modèle n’a jamais été repris ailleurs
La raison est moins technique qu’industrielle et historique.
POSIX et Win32 sont des prisons technologiques. Linux/macOS s’appuient sur POSIX, Windows sur Win32 deux standards figés dans les années 70-90, qui imposent système de fichiers hiérarchique, chemins, exécutables, mémoire séparée du stockage. Un modèle objet pur ne peut pas s’y greffer sans tout casser : drivers, applications, compilateurs, frameworks. Adopter ce modèle aujourd’hui reviendrait à sacrifier des décennies de logiciels existants, un coût qu’aucune entreprise ni aucun éditeur ne peut se permettre.
IBM i a eu la chance du timing. Il est né dans les années 80-90, avant que le marché ne soit saturé de logiciels POSIX/Windows. Un OS objet pur lancé aujourd’hui serait rejeté : incompatible avec l’existant, trop coûteux à migrer, trop différent pour des développeurs formés à C/C++/Rust et au modèle procédural classique.
Le grand public ne veut pas de ce niveau de contrôle. IBM i dit : tout est un objet, tout est contrôlé, tout est cohérent. C’est parfait pour l’entreprise, mais trop strict pour qui veut bricoler, charger des modules, faire du reverse engineering ou compiler n’importe quoi.
Pourquoi IBM i n’a (quasiment) jamais eu de virus
Ce n’est pas une question de discipline ou d’antivirus efficace : c’est l’architecture elle-même qui ferme les portes.
- Pas de fichiers exécutables classiques : un virus est un fichier qui s’exécute ; IBM i ne connaît que des objets typés et validés.
- Pas de mémoire « corruptible » au sens buffer overflow : la mémoire est un espace d’objets typés, pas un tas d’octets manipulables.
- Drivers en tant qu’objets système contrôlés, pas de modules chargés dynamiquement façon rootkit.
- Aucune exécution de code arbitraire ni de binaire non signé.
La sécurité n’est pas une couche ajoutée après coup (comme SELinux sur Linux ou l’UAC sur Windows) : elle fait partie de la structure même du système.
IBM i vs Windows NT vs Linux, en bref
| IBM i | Windows NT | Linux | |
| Modèle | Objets typés, persistants | Hybride fichiers/API Win32 | Héritage Unix : fichiers, processus, pipes |
| Sécurité | Intrinsèque, par architecture | Ajoutée (ACL, UAC, antivirus) | Ajoutée par couches (SELinux, AppArmor, cgroups) |
| Stockage | Single-level store (mémoire = stockage) | Mémoire séparée du disque | Mémoire séparée du disque |
| Compatibilité | Ascendante quasi parfaite depuis 1988 | Large mais fragile (drivers, registre) | Bonne mais fragmentée entre distributions |
Windows NT et Linux restent d’excellents systèmes, mais ce sont des patchworks historiques qui ont dû ajouter la sécurité et la cohérence après coup. IBM i a été pensé d’un seul bloc. Nous détaillons d’ailleurs cette comparaison dans un précédent article, pourquoi l’IBM i est toujours d’actualité en 2026.
Pourquoi IBM i reste central dans les banques et assurances
Ces secteurs recherchent avant tout la fiabilité, pas les gadgets.
- Transactions ACID natives : pas de perte de données, pas de rollback hasardeux, la transaction est native, pas ajoutée par une couche externe.
- Absence quasi totale de malware/ransomware, pour les raisons architecturales vues plus haut.
- Haute disponibilité native : clustering et réplication intégrés, redondance matérielle.
- Coût de maintenance réduit : pas de fragmentation, pas de dépendances cassées, pas de cycle de patchs hebdomadaires.
- Longévité : une plateforme stable sur 40 ans, sans rupture de paradigme, exactement ce qu’un secteur régulé recherche. C’est d’ailleurs cette longévité qui impose une vigilance particulière sur les cycles de support, comme on le voit avec la fin du support standard d’IBM i 7.4 prévue pour septembre 2026.
Ce qu’un OS moderne (ou futur) pourrait en retenir
Si un système d’exploitation de 2035 voulait vraiment rompre avec l’héritage Unix/Windows, plusieurs idées d’IBM i pointent la direction :
- Mémoire unifiée (single-level store) pour éliminer corruption et fragmentation.
- Objets typés à la place des fichiers/DLL/binaires arbitraires, pour fermer par construction les portes du malware.
- Sécurité par conception plutôt qu’ajoutée après coup plus besoin d’antivirus.
- Base de données intégrée au système de fichiers/registre, pour éliminer les incohérences OS/DB.
- Compatibilité ascendante réelle, sans rupture d’API ni migrations forcées.
Le frein n’est pas technique : c’est l’héritage POSIX/Win32 et le volume de logiciels existants qui rendent une telle refonte quasiment impossible à imposer aujourd’hui.
IBM i, un OS « post-Unix » avant l’heure
IBM i n’est pas une évolution d’Unix : c’est un système conçu hors des contraintes POSIX, dès 1988, avec des objectifs qu’Unix pensé en 1970 pour être simple et hackable n’a jamais visés : robustesse, cohérence, transactionnalité, sécurité intrinsèque.
D’une certaine manière, IBM i ressemble presque plus à un langage qu’à un OS : chaque objet a un type, des règles, une sémantique stricte, une persistance garantie un peu ce que les langages modernes comme Rust ou Erlang tentent d’obtenir, mais porté au niveau du système tout entier. RPG, COBOL, C, Java, SQL, CL s’y exécutent tous dans ce même environnement typé et cohérent, ce qui rapproche l’OS d’une machine virtuelle orientée objet plutôt que d’un système classique.
Conclusion
IBM i n’est pas seulement un « bon vieux système ». C’est un concept architectural cohérent de bout en bout, conçu sans compromis avec un héritage Unix ou Windows, avec une sécurité intrinsèque et une stabilité que ni Windows NT ni Linux,brillants par ailleurs, mais construits par couches successives n’ont jamais pu atteindre. C’est aussi pour ça qu’il continue de régner dans les secteurs où la fiabilité n’est pas négociable.
Envie d’échanger sur votre environnement IBM i ? Nos équipes IBM i accompagnent l’audit, la maintenance et la modernisation de plateformes critiques, et notre Pépinière i forme chaque année de nouveaux consultants pour renforcer les compétences sur cette technologie.
