Plateforme infrastructure fiable : ce que Matthew Liste enseigne aux PME

Combien d'heures vos équipes perdent-elles chaque semaine à cause d'un serveur lent, d'un accès bloqué ou d'une sauvegarde dont personne ne sait si elle tourne encore ? Ce temps n'apparaît sur aucune facture. Il est pourtant retiré directement à votre cœur de métier.

Matthew Liste, responsable mondial de l'infrastructure chez American Express, conçoit des plateformes utilisées par environ 20 000 développeurs internes. Chez JPMorganChase, ce chiffre atteignait 60 000. Lors d'une conférence QCon, il a formalisé 12 principes pour bâtir une plateforme infrastructure fiable. Leur logique dépasse largement le monde bancaire.

Une bonne plateforme ressemble à votre plomberie

Matthew Liste utilise une analogie peu glamour mais juste : la plomberie. L'eau arrive, les eaux usées repartent, et personne n'y pense. Le réseau ne devient visible que le jour où il casse.

Sa définition technique est simple : une plateforme est un ensemble de technologies intégrées qui sert de fondation pour construire des applications. AWS, Azure et Google Cloud en sont les exemples les plus connus. Ils fournissent des briques d'architecture cloud sur lesquelles les développeurs écrivent leur logiciel sans se soucier du matériel.

Son parcours explique sa rigueur. Il a débuté dans les systèmes embarqués offshore pour l'acquisition de données sismiques, puis dans les télécoms. Il a ensuite passé près de dix ans chez Goldman Sachs, neuf ans chez JPMorganChase, et un peu plus de deux ans chez American Express. Dans la banque, l'infrastructure qui porte des logiciels critiques n'a pas le droit de tomber.

Dans une PME, la plateforme n'a évidemment pas cette taille. Elle se résume souvent à un hébergement, un ERP, une messagerie, quelques outils SaaS et des scripts accumulés au fil des années. Le principe reste identique : quand elle fait bien son travail, personne ne sait qu'elle existe.

Précision utile : Liste insiste sur le fait que ses 12 principes ne suivent aucun ordre d'importance. Il les a regroupés pour la fluidité de sa présentation, pas pour établir une hiérarchie. Le premier n'est donc pas plus important que le douzième.

Masquer la complexité : le principe de l'intuitivité

Le premier principe porte sur l'intuitivité. Pour Liste, intuitif signifie évident, transparent, et surtout : ça fonctionne. Une bonne plateforme cache sa complexité au point de paraître magique. Il cite Arthur C. Clarke : « Toute technologie suffisamment avancée est indiscernable de la magie. »

Il illustre ce cycle avec l'IA générative. Ses deux enfants adolescents l'ont intégrée à tout ce qu'ils font et n'imaginent plus s'en passer. La technologie est passée de l'impossible à la magie, puis à l'évidence, en très peu de temps.

L'argument central est économique. Personne n'a la capacité cognitive de tout maîtriser. Si vous pouvez vous spécialiser dans votre métier, c'est parce que d'autres se sont spécialisés dans le leur et vous ont construit des fondations. Le fournisseur de plateforme gère une complexité pour que vous puissiez gérer la vôtre.

Liste reprend aussi une phrase attribuée à Steve Jobs : la simplicité est la sophistication suprême, et elle exige un travail important pour comprendre les problèmes sous-jacents.

Dans une PME, ce principe se traduit de manière très concrète. Votre comptable ne devrait pas savoir sur quel serveur tourne la facturation. Votre commercial ne devrait pas relancer un script à la main chaque lundi. Chaque fois qu'un collaborateur doit comprendre l'infrastructure pour faire son travail, la plateforme échoue sur ce premier critère. C'est précisément le rôle de l'automatisation IT et des pratiques DevOps : absorber les tâches répétitives pour que personne n'ait plus à les connaître.

Des briques qui s'emboîtent comme des Lego

Le deuxième principe découle de la définition : une plateforme n'est pas un produit unique, c'est un ensemble de composants. Les fournisseurs cloud en proposent des centaines, et tous fonctionnent de manière cohérente.

Liste prend l'image des Lego. Avec un nombre fini de pièces, vous construisez un dinosaure, une voiture ou une tour Eiffel. La raison : toutes les briques partagent la même interface pour s'assembler. Sans cette interface commune, vous obtenez une collection d'outils, pas une plateforme.

Il défend une idée qu'il nomme la liberté de ne pas choisir. Chaque composant doit reposer sur les mêmes fondations :

• la même base d'observabilité, pour surveiller toute la chaîne depuis un seul endroit ;
• la même gestion des identités, pour qu'un utilisateur soit reconnu partout de la même façon ;
• le même espace de nommage, pour retrouver chaque ressource sans ambiguïté.

Il ajoute un point souvent négligé : la facturation commune. Le cloud vous facture l'ensemble de vos services sur une seule note. Cet aspect financier fait partie intégrante de la plateforme.

Pour une PME, la question est simple. Vos logiciels partagent-ils un annuaire d'utilisateurs, ou chacun gère-t-il ses propres comptes et mots de passe ? Vos alertes arrivent-elles au même endroit ? Attention toutefois à ne pas confondre interchangeable et totalement indépendant. Des composants qui ne partagent plus aucun contrat deviennent vite ingérables, un piège détaillé dans cette analyse sur les microservices et le couplage zéro.

Stabilité, sécurité, scalabilité : le tabouret à trois pieds

Le troisième principe regroupe ce que Liste appelle les trois S. Il les compare à un tabouret à trois pieds : il ne tient debout que si les trois pieds tiennent.

La stabilité d'abord. Une plateforme qui tombe régulièrement perd ses utilisateurs, car ils ne peuvent pas compter sur elle. Le niveau de disponibilité se mesure en « neuf » : 99,9 %, 99,99 %, et ainsi de suite. Pour Liste, ce choix relève d'une décision commerciale. Chez American Express, les systèmes d'autorisation des cartes bancaires fonctionnent à six ou sept neuf. Une application mobile tolère davantage d'interruptions.

La sécurité ensuite. Dans la banque, les clients confient leur argent, la question ne se discute pas. Dans une PME, ce sont les données clients, les devis et la comptabilité qui sont en jeu.

La scalabilité enfin. Liste reconnaît avoir construit des plateformes qui fonctionnaient jusqu'au jour où elles ne fonctionnaient plus. Les utilisateurs ont adopté l'outil, la consommation s'est emballée et des goulets d'étranglement sont apparus. Sa leçon : un produit apprécié attire les usages, donc les volumes. Il faut l'anticiper.

Mon conseil est de calibrer chaque pied selon l'enjeu réel. Viser sept neuf pour un site vitrine n'a aucun sens économique : chaque neuf supplémentaire coûte en redondance et en supervision. À l'inverse, un ERP qui bloque la production une journée coûte bien plus cher qu'un hébergement mieux dimensionné. Vérifier l'équilibre de ces trois pieds constitue d'ailleurs le point de départ logique d'un audit de sécurité, où fiabilité système et protection des données s'évaluent ensemble.

Dette technique et dépréciation : la fiabilité se joue dans la durée

Parmi les 12 principes, plusieurs concernent le temps long : éviter la dette technique, gérer la dépréciation des composants et construire une culture d'ingénierie solide. Ce sont eux qui distinguent une plateforme durable d'un empilement d'outils qui fonctionne... pour l'instant.

La dette technique, c'est chaque raccourci pris pour livrer plus vite : un script sans documentation, une version de PHP jamais mise à jour, un serveur configuré à la main que personne n'ose toucher. Elle ne coûte rien le jour où vous la contractez. Elle se rembourse avec intérêts lors de la prochaine panne ou de la prochaine faille.

La dépréciation est l'autre face du problème. Tout composant a une date de fin de vie, qu'il s'agisse d'un système d'exploitation, d'un framework ou d'un logiciel SaaS racheté puis abandonné. Une plateforme fiable prévoit le retrait de ses briques, pas seulement leur ajout. Concrètement, cela implique de tenir un inventaire des outils utilisés avec leur date de fin de support, et de planifier les migrations avant qu'elles ne deviennent urgentes.

Je constate souvent le même schéma : l'outil qui « marche » n'est jamais remplacé, jusqu'au jour où il devient impossible à maintenir. La migration se fait alors dans l'urgence, au pire moment.

La culture d'ingénierie complète ce trio. Les équipes de Site Reliability Engineering, popularisées par Google, en sont une illustration : analyse systématique des incidents sans chercher de coupable, et temps réservé à la réduction de la dette. Une PME peut adopter ces réflexes sans créer de service dédié.

Pourquoi investir dans le platform engineering pour une PME ?

Le platform engineering consiste à construire une plateforme interne qui fournit aux équipes des outils prêts à l'emploi, plutôt que de laisser chacun réinventer son environnement. Chez American Express, c'est une organisation entière au service de 20 000 développeurs.

Il faut être clair sur les limites. Les principes de Matthew Liste sont nés dans des environnements où l'indisponibilité a un coût direct et immédiat, avec des milliers d'ingénieurs à servir. Les appliquer à la lettre dans une TPE relèverait de la sur-ingénierie. Monter une équipe plateforme dédiée n'a de sens qu'avec plusieurs équipes de développement internes, ce qui exclut la grande majorité des PME.

Ce qui se transpose, c'est la philosophie. Pour une infrastructure IT PME, quatre actions suffisent souvent à changer la donne :

• recenser ce que vos équipes font à la main chaque semaine et automatiser en priorité les tâches les plus fréquentes ;
• unifier l'identité des utilisateurs et la supervision de vos outils ;
• fixer un niveau de disponibilité par outil, selon son poids réel dans votre chiffre d'affaires ;
• planifier les fins de vie de vos logiciels plutôt que de les subir.

Le retour sur investissement se mesure en temps récupéré et en incidents évités. Une plateforme cohérente réduit aussi la dépendance à la seule personne qui « sait comment ça marche », un risque fréquent dans les petites structures. Enfin, elle facilite la scalabilité : ajouter un collaborateur, une agence ou un service devient une opération de routine, pas un projet.

Questions fréquentes

Quels sont les 12 principes de Matthew Liste ?

Matthew Liste présente 12 principes sans ordre d'importance. Parmi les plus développés figurent l'intuitivité qui masque la complexité, les composants interchangeables reposant sur des fondations communes, et les trois S : stabilité, sécurité, scalabilité. Les autres portent notamment sur la maîtrise de la dette technique, la gestion de la dépréciation et la culture d'ingénierie. La présentation complète est disponible en vidéo sur InfoQ.

Comment construire une plateforme infrastructure fiable ?

Commencez par masquer la complexité aux utilisateurs finaux en automatisant les tâches répétitives. Assurez-vous ensuite que vos outils partagent les mêmes fondations : identité, supervision, conventions de nommage. Calibrez enfin la disponibilité, la sécurité et la capacité de chaque composant selon son enjeu commercial, et planifiez dès le départ le remplacement des briques en fin de vie.

Le platform engineering est-il réservé aux grandes entreprises ?

L'organisation l'est, la philosophie non. Une PME n'a pas besoin d'une équipe plateforme dédiée, mais elle tire profit des mêmes réflexes : cohérence des outils, automatisation et anticipation. L'essentiel est de dimensionner l'effort à la taille réelle de l'activité.

Une infrastructure qui se fait oublier

La leçon de Matthew Liste tient en une idée : une plateforme fiable est celle dont personne ne parle, parce qu'elle absorbe la complexité à la place de ceux qui créent de la valeur. Cette exigence ne dépend pas de la taille de l'entreprise, seulement de la volonté de traiter l'infrastructure comme un produit plutôt que comme une contrainte.

Aujourd'hui, combien de vos collaborateurs doivent comprendre votre infrastructure pour simplement faire leur travail ?

Sources : InfoQ : Building Resilient Platforms: Insights from 20+ Years in Mission-Critical Infrastructure (Matthew Liste, QCon)