
Quiconque a étudié la philosophie, et plus particulièrement la logique, sait qu’il existe un large éventail de sophismes qui finissent par affaiblir une argumentation. La plupart des gens connaissent probablement le sophisme ad hominem qui consiste à tenter de réfuter l’argument d’un adversaire en s’attaquant à sa personne plutôt qu’à son argument.
De même, il existe le sophisme de la diversion qui consiste à changer délibérément de sujet pour éviter toute discussion sur la prémisse initiale, généralement en remettant en question un aspect de l’argument de départ. Par exemple, on pourrait répondre à l’affirmation « Il n’est pas moral de mentir » par « Que signifie moral ? »
Un autre sophisme assez courant, mais qui, pour une raison quelconque, est rarement relevé, est celui du faux dilemme, qui consiste à supposer que seuls deux choix sont possibles. L’exemple le plus courant est : « Soit vous êtes avec nous, soit vous êtes contre nous. » Ou encore : « Vous pouvez prendre la pilule rouge ou la pilule bleue », alors qu’il existe au moins deux autres possibilités : ne prendre ni l’une ni l’autre, ou prendre les deux.
C’est un peu comme le débat actuel sur les formats. On peut choisir soit le logiciel, soit le matériel. Sauf que ce ne sont pas les seules options : on peut choisir les deux.
Il s’avère que c’est exactement ce que préfèrent la plupart des professionnels de l’informatique : un mélange de matériel et de logiciels. Cela s’explique probablement à la fois par la poursuite de la bifurcation du réseau et par celle du centre de données, certaines applications étant hébergées dans le cloud, où les solutions logicielles sont incontournables, tandis que d’autres se trouvent dans le centre de données, où des solutions matérielles ou logicielles sont disponibles.

En réalité, il s’avère que les préférences en matière de format dépendent du rôle du professionnel de l’informatique au sein du centre de données. Dans notre rapport 2016 sur l’État de la fourniture d’applications, les professionnels de l’informatique qui préféraient le matériel aux logiciels étaient ceux qui déclaraient occuper des fonctions liées au « réseau » et à la « sécurité ». Sans surprise, ce sont les domaines de l’informatique où l’évolutivité, la rapidité et la sécurité des données, des applications, voire des systèmes eux-mêmes, sont essentielles à la réussite quotidienne de l’entreprise.
En réalité, il s’avère que le matériel est plus performant dans certains domaines que ses équivalents logiciels. La sécurité en fait souvent partie, tout comme les performances et la capacité à monter en charge.
Cela s’explique par le fait que le matériel est généralement conçu spécifiquement pour un usage donné. Par exemple, les architectures de commutateurs (qui sont très différentes des architectures informatiques généralistes) sont conçues pour offrir un débit élevé et une grande capacité de montée en charge. C’est pourquoi un commutateur de classe entreprise ou opérateur peut traiter un trafic de 100 Gbit/s, contrairement à mon ordinateur portable. En revanche, ce même commutateur ne peut pas faire tourner Angry Birds : l’informatique généraliste a donc au moins un avantage.
Le matériel ne sert pas uniquement à fournir des ressources de calcul, de stockage et de réseau. Certes, c’est une grande partie de son rôle, car les ressources nécessaires à la mise à disposition des applications n’apparaissent pas comme par magie lorsqu’une licorne traverse le centre de données en répandant de la « poussière de ressources » avec sa corne enchantée. Les ressources proviennent forcément d’un matériel quelconque. Mais il faut parfois aussi tenir compte de la manière dont ce matériel interagit avec ces ressources et les gère. Dans le réseau, le matériel spécialisé reste non seulement précieux, mais aussi indispensable pour garantir la vitesse, l’évolutivité et la sécurité des données qu’il traite. Sans cela, il faut se lancer dans une démarche visant à reproduire les mêmes résultats par des moyens architecturaux. Faire évoluer horizontalement des logiciels à l’aide d’autres logiciels n’est pas impossible ; cela se fait tous les jours. Mais il en résulte un environnement bien moins stable, comportant beaucoup plus d’éléments mobiles, chacun étant susceptible de tomber en panne et de perturber l’activité.

Si vous pensiez qu’il s’agissait d’un article du genre « Vive le matériel, oubliez le logiciel ! », détrompez-vous, car ce serait là aussi un faux dilemme. Ce n’est pas non plus la bonne réponse. Il existe de bonnes raisons de préférer le logiciel au matériel, notamment lorsque l’on considère les besoins et les exigences des applications ainsi que les méthodologies émergentes qui privilégient l’agilité et la rapidité, telles que les microservices et le DevOps. Dans le cloud, bien sûr, il n’y a vraiment aucun choix : le logiciel s’impose, un point c’est tout. Cela ressortait également de notre enquête : les personnes déclarant occuper des fonctions liées aux « applications », à « l’infrastructure » ou au « cloud/DevOps » préféraient le logiciel au matériel. Pour les professionnels des applications et de l’infrastructure, l’écart était considérable. Cela s’explique par le fait que le logiciel est jugé mieux adapté à leur domaine, qui se concentre sur des applications et des services applicatifs devant être agiles, faciles à déployer et capables de réagir rapidement aux évolutions de l’environnement.
Mais il s’avère que tous les profils préfèrent un modèle hybride associant matériel et logiciel. En effet, le matériel comme le logiciel ont chacun leurs avantages, et tout dépend en réalité de ce que vous cherchez à accomplir — et dans quel environnement.
Ne laissez donc personne vous acculer et vous imposer le faux dilemme « logiciel ou matériel ». Les deux sont adaptés, et chacun présente des avantages et des inconvénients selon l’environnement, l’application et l’usage précis auquel vous destinez la solution.
Comme pour le cloud, il ne s’agit pas de choisir entre l’un ou l’autre. Les deux sont complémentaires.
À propos de l’auteur

Lori MacVittie est ingénieure émérite et évangéliste en chef au sein du bureau du directeur technique de F5. Elle possède une expertise approfondie dans la fourniture d’applications, les stratégies d’automatisation et les infrastructures. Elle est réputée pour sa capacité à rendre la complexité intelligible, qu’elle définisse des garde-fous pour les agents d’IA, analyse des architectures multicloud fragiles ou explore les limites des systèmes évolutifs. Elle cumule plus de trente ans d’expérience dans le secteur, couvrant le développement d’applications, l’architecture informatique ainsi que l’exploitation des réseaux et des systèmes. Avant de rejoindre F5, elle a été rédactrice spécialisée dans les technologies et a reçu plusieurs distinctions. MacVittie est titulaire d’un master en informatique et est une autrice prolifique dont les publications couvrent la sécurité, le cloud et l’architecture d’entreprise. Elle est également une passionnée de jeux de société et de jeux vidéo, et assume pleinement ses avis bien tranchés sur le fromage.
Autres articles de Lori Mac VittieArticles de blog associés

F5 NGINXaaS pour Google Cloud : des applications résilientes et évolutives
Découvrez comment NGINXaaS s’intègre à Google Cloud pour renforcer les performances et la sécurité, et préparer vos applications critiques à un avenir propulsé par l’IA.
L’intégration de F5 Web Application Firewall (WAF) à AWS est disponible dès aujourd’hui
En faisant appel à un partenaire de déploiement AWS WAF tel que F5, vous pouvez renforcer la sécurité de vos applications web grâce à des règles personnalisées qui bloquent les schémas d’attaque courants, comme les injections SQL ou les attaques par scripts intersites (XSS).
Appliquer le principe de Peter Parker à l’inspection TLS
« Un grand pouvoir implique de grandes responsabilités. » Si l’on en trouve des échos chez Voltaire et Churchill, cette citation est surtout connue grâce aux bandes dessinées Spider-Man, où elle est attribuée à l’oncle Ben. Bien entendu, si cette phrase est si répandue dans la culture populaire, c’est notamment parce qu’elle peut s’appliquer à une multitude de situations et de sujets, y compris à l’inspection TLS.
Le NetOps a besoin de défenseurs, pas d’adversaires
Il est important de reconnaître que les équipes NetOps ne sont pas toujours celles qui font obstacle au déploiement de la dernière nouveauté, application ou service. Les freins à la rapidité sont souvent dus au fait que les organisations n’adoptent pas tous les principes du DevOps lorsqu’elles cherchent à transformer leurs opérations informatiques.
Mise à jour des services applicatifs : sécurité, rapidité et visiteurs suspects
Il est de nouveau temps de nous pencher sur les services applicatifs que les entreprises utilisent réellement pour rendre leurs applications plus rapides et plus sûres. On constate notamment une hausse du recours aux services de protection contre les bots, ainsi que la progression lente mais régulière de HTTP/2. Bien qu’il ne s’agisse pas d’une application…
Les templates prennent le contrôle du cloud
Les modèles s’imposent dans le cloud. Lisez le blog de F5 pour découvrir comment l’infrastructure en tant que code et les API déclaratives automatisent la mise à disposition des applications.