Découvrez comment Bob Kahn a contribué à façonner TCP/IP, pourquoi un réseau à paquets fiable importe, et comment sa conception soutient encore aujourd’hui les apps, les API et les services cloud.
La plupart des applications semblent « instantanées » : vous touchez un bouton, un fil d’actualité se met à jour, un paiement s’achève, une vidéo démarre. Ce que vous ne voyez pas, c’est le travail qui se déroule en dessous pour déplacer de petits paquets de données à travers le Wi‑Fi, les réseaux mobiles, les routeurs domestiques et les centres de données — souvent à travers plusieurs pays — sans que vous ayez à penser aux parties embrouillées entre les deux.
Cette invisibilité est la promesse de TCP/IP. Ce n’est pas un produit unique ni une fonctionnalité cloud. C’est un ensemble de règles partagées qui permet aux appareils et aux serveurs de se parler d’une manière qui la plupart du temps paraît fluide et fiable, même quand le réseau est bruyant, congestionné ou partiellement défaillant.
Bob Kahn a été l’une des personnes clés qui a rendu cela possible. Avec des collaborateurs comme Vint Cerf, Kahn a contribué à façonner les idées centrales qui sont devenues TCP/IP : un « langage » commun pour les réseaux et une méthode pour livrer des données de façon à ce que les applications puissent y faire confiance. Pas de battage médiatique — ce travail a compté parce qu’il a transformé des connexions peu fiables en quelque chose sur lequel le logiciel pouvait construire de façon fiable.
Au lieu d’envoyer un message entier comme un flux continu, le réseau par paquets le découpe en petites pièces appelées paquets. Chaque paquet peut emprunter son propre chemin vers la destination, comme des enveloppes séparées passant par différents bureaux de poste.
Nous allons expliquer comment TCP crée la sensation de fiabilité, pourquoi IP ne promet pas la perfection et comment la mise en couches rend le système compréhensible. À la fin, vous pourrez imaginer ce qui se passe lorsqu’une application appelle une API — et pourquoi ces idées, vieilles de plusieurs décennies, alimentent encore les services cloud modernes.
Les premiers réseaux informatiques n’ont pas été conçus comme « l’Internet ». Ils étaient construits pour des groupes et des objectifs spécifiques : un réseau universitaire ici, un réseau militaire là, un réseau de laboratoire de recherche ailleurs. Chacun pouvait bien fonctionner en interne, mais ils utilisaient souvent des matériels, des formats de messages et des règles de transport différentes.
Cela créait une réalité frustrante : même si deux ordinateurs étaient « en réseau », ils pouvaient ne pas être capables d’échanger des informations. C’est un peu comme avoir plusieurs systèmes ferroviaires dont les voies ont des largeurs différentes et dont les signaux n’ont pas la même signification. On peut faire circuler des trains à l’intérieur d’un système, mais passer dans un autre système est compliqué, coûteux ou impossible.
Le défi de Bob Kahn n’était pas simplement « connecter l’ordinateur A à l’ordinateur B ». C’était : comment connecter des réseaux entre eux pour que le trafic puisse traverser plusieurs systèmes indépendants comme s’ils formaient un système plus grand ?
C’est ce que signifie « internetworking » — construire une méthode pour que les données sautent d’un réseau à l’autre, même lorsque ces réseaux sont conçus différemment et gérés par des organisations distinctes.
Pour que l’internetworking fonctionne à grande échelle, tout le monde avait besoin d’un ensemble commun de règles — des protocoles — qui ne dépendent pas de la conception interne d’un réseau particulier. Ces règles devaient aussi refléter des contraintes réelles :
TCP/IP est devenu la réponse pratique : un « accord » partagé qui permettait à des réseaux indépendants de s’interconnecter et de transférer des données de façon suffisamment fiable pour les applications réelles.
Bob Kahn est surtout connu comme l’un des architectes des « règles de la route » d’Internet. Dans les années 1970, alors qu’il travaillait pour la DARPA, il a contribué à faire passer le réseautage d’une expérimentation de recherche astucieuse à quelque chose capable de connecter de nombreux types de réseaux différents — sans les forcer à utiliser le même matériel, câblage ou conception interne.
ARPANET a prouvé que les ordinateurs pouvaient communiquer via des liaisons par commutation de paquets. Mais d’autres réseaux apparaissaient aussi — systèmes radio, liaisons satellites, réseaux expérimentaux supplémentaires — chacun avec ses propres particularités. L’objectif de Kahn était l’interopérabilité : permettre à un message de voyager à travers plusieurs réseaux comme si c’était un seul réseau.
Plutôt que de construire un réseau « parfait », il a promu une approche où :
Avec Vint Cerf, Kahn a co‑conçu ce qui est devenu TCP/IP. Un résultat durable fut la séparation claire des responsabilités : IP gère l’adressage et l’acheminement entre réseaux, tandis que TCP gère la livraison fiable pour les applications qui en ont besoin.
Si vous avez déjà appelé une API, chargé une page web ou envoyé des logs d’un conteneur vers un service de monitoring, vous comptez sur le modèle d’internetworking que Kahn a défendu. Vous n’avez pas à vous soucier que les paquets traversent le Wi‑Fi, la fibre, le LTE ou un backbone cloud. TCP/IP présenté tout cela comme un système continu — ainsi le logiciel peut se concentrer sur les fonctionnalités, pas sur le câblage.
Une des idées les plus intelligentes derrière TCP/IP est la mise en couches : au lieu de construire un énorme système réseau « qui fait tout », on empile de plus petites pièces où chaque couche fait bien une seule tâche.
C’est important parce que les réseaux ne sont pas tous identiques. Différents câbles, radios, routeurs et fournisseurs peuvent quand même interopérer quand ils s’accordent sur quelques responsabilités claires.
Pensez à IP (Internet Protocol) comme la partie qui répond : Où vont ces données, et comment les rapprocher de cette destination ?
IP fournit des adresses (pour identifier les machines) et un routage basique (pour que les paquets sautent d’un réseau à l’autre). Important : IP n’essaie pas d’être parfait. Il se concentre sur l’acheminement des paquets étape par étape, même si le chemin change.
Ensuite, TCP (Transmission Control Protocol) s’installe au‑dessus d’IP et répond : Comment rendre ça dépendable ?
TCP gère le travail de « fiabilité » que les applications demandent généralement : ordonner correctement les données, détecter les morceaux manquants, réessayer si nécessaire et réguler la livraison pour que l’émetteur n’écrase pas le récepteur ou le réseau.
Une façon utile d’imaginer la séparation :
Vous ne demandez pas à l’adresse de garantir l’arrivée du colis ; vous construisez cette assurance au‑dessus.
Parce que les responsabilités sont séparées, vous pouvez améliorer une couche sans repenser tout le reste. De nouveaux réseaux physiques peuvent transporter IP, et les applications peuvent compter sur le comportement de TCP sans avoir à comprendre comment le routage fonctionne. Cette division claire est une raison majeure pour laquelle TCP/IP est devenu la fondation invisible sous presque toutes les applications et API que vous utilisez.
La commutation de paquets est l’idée qui a rendu les grands réseaux pratiques : au lieu de réserver une ligne dédiée à votre message complet, vous découpez le message en petites pièces et envoyez chaque pièce indépendamment.
Un paquet est un petit ensemble de données avec un en‑tête (qui l’envoie, qui le reçoit et des infos de routage) plus un morceau du contenu.
Découper les données en morceaux aide parce que le réseau peut :
C’est là que commence le « chaos ». Les paquets d’un même téléchargement ou appel d’API peuvent emprunter différents chemins dans le réseau, selon ce qui est occupé ou disponible à cet instant. Cela signifie qu’ils peuvent arriver hors ordre — le paquet n°12 peut arriver avant le n°5.
La commutation de paquets ne cherche pas à empêcher cela. Elle privilégie la rapidité de passage des paquets, même si l’ordre d’arrivée est désordonné.
La perte de paquets n’est pas rare, et ce n’est pas toujours la faute de quelqu’un. Causes courantes :
Le choix de conception clé est d’autoriser le réseau à être imparfait. IP se concentre sur l’acheminement des paquets du mieux possible, sans promettre la livraison ou l’ordre. Cette liberté permet aux réseaux de monter en charge — et c’est pourquoi des couches supérieures (comme TCP) existent pour nettoyer le chaos.
IP livre des paquets sur une base « au mieux » : certains peuvent arriver en retard, hors ordre, dupliqués ou pas du tout. TCP se place au‑dessus et crée quelque chose sur lequel les applications peuvent compter : un flux d’octets unique, ordonné et complet — le type de connexion que vous attendez quand vous téléversez un fichier, chargez une page web ou appelez une API.
Quand on dit que TCP est « fiable », on entend généralement :
TCP découpe vos données en morceaux et les étiquette avec des numéros de séquence. Le récepteur renvoie des accusés de réception (ACKs) pour confirmer ce qu’il a reçu.
Si l’émetteur ne voit pas d’ACK à temps, il suppose qu’un paquet a été perdu et effectue une rétransmission. C’est l’illusion centrale : même si le réseau laisse tomber des paquets, TCP continue d’essayer jusqu’à ce que le récepteur confirme la réception.
Ils semblent similaires mais résolvent des problèmes différents :
Ensemble, ils aident TCP à rester rapide sans être imprudent.
Un timeout fixe échouerait sur des réseaux lents et rapides. TCP ajuste continuellement son timeout en fonction du temps de trajet mesuré. Si les conditions se détériorent, il attend plus longtemps avant de renvoyer ; si tout s’accélère, il devient plus réactif. Cette adaptation explique pourquoi TCP fonctionne sur le Wi‑Fi, les réseaux mobiles et les liaisons longue distance.
Une des idées les plus importantes de TCP/IP est le principe de bout en bout : placez l’intelligence aux extrémités du réseau (les endpoints) et gardez le milieu du réseau relativement simple.
En clair, les endpoints sont les appareils et programmes qui se préoccupent réellement des données : votre téléphone, votre laptop, un serveur, et les systèmes d’exploitation et applications qui tournent dessus. Le cœur du réseau — routeurs et liaisons intermédiaires — se concentre principalement sur le transport des paquets.
Plutôt que d’essayer de rendre chaque routeur « parfait », TCP/IP accepte que le milieu soit imparfait et laisse les endpoints gérer les parties qui demandent du contexte.
Garder le cœur plus simple a facilité l’expansion d’Internet. De nouveaux réseaux pouvaient se joindre sans exiger que chaque appareil intermédiaire comprenne les besoins de chaque application. Les routeurs n’ont pas besoin de savoir si un paquet fait partie d’un appel vidéo, d’un téléchargement ou d’une requête d’API — ils le transmettent simplement.
Aux endpoints, on gère généralement :
Dans le réseau, on gère surtout :
La pensée bout en bout évolue bien, mais elle pousse la complexité vers l’extérieur. Les systèmes d’exploitation, bibliothèques et applications deviennent responsables de « faire fonctionner » les choses sur des réseaux désordonnés. C’est flexible, mais cela signifie aussi que bugs, timeouts mal configurés ou retries trop agressifs peuvent créer des problèmes visibles pour les utilisateurs.
IP (Internet Protocol) fait une promesse simple : il va tenter de faire avancer vos paquets vers leur destination. C’est tout. Pas de garantie sur l’arrivée, la singularité, l’ordre ou le délai.
Cela peut paraître un défaut — jusqu’à ce qu’on regarde ce dont Internet avait besoin pour devenir : un réseau mondial composé de nombreux réseaux plus petits, possédés par des organisations différentes et constamment changeants.
Les routeurs sont les « directeurs de trafic » d’IP. Leur tâche principale est le forwarding : quand un paquet arrive, le routeur regarde l’adresse de destination et choisit le prochain saut qui semble le meilleur pour l’instant.
Les routeurs ne suivent pas une conversation comme un standard téléphonique. Ils ne réservent généralement pas de capacité pour vous et n’attendent pas la confirmation qu’un paquet est passé. En gardant les routeurs concentrés sur le forwarding, le cœur du réseau reste simple — et peut évoluer pour des milliards d’appareils et de connexions.
Les garanties coûtent cher. Si IP essayait de garantir la livraison, l’ordre et les délais pour chaque paquet, chaque réseau sur Terre devrait se coordonner étroitement, stocker beaucoup d’état et récupérer des pannes de la même façon. Ce fardeau coordinationnel ralentirait la croissance et rendrait les incidents plus graves.
À la place, IP tolère le désordre. Si un lien tombe, un routeur peut utiliser un trajet différent. Si un chemin est congestionné, des paquets peuvent être retardés ou perdus, mais le trafic peut souvent continuer par des routes alternatives.
Le résultat est la résilience : Internet continue de fonctionner même quand des parties se cassent ou changent — parce que le réseau n’est pas obligé d’être parfait pour être utile.
Quand vous fetch() une API, cliquez sur « Enregistrer » ou ouvrez un websocket, vous ne « parlez » pas au serveur en un flux lisse. Votre application donne des données au système d’exploitation, qui les découpe en paquets et les envoie à travers de nombreux réseaux séparés — chaque saut prenant ses propres décisions.
Surprise courante : vous pouvez avoir un excellent débit et une interface lente parce que chaque requête attend des aller‑retour.
TCP réessaie les paquets perdus, mais il ne sait pas ce que « trop long » signifie pour votre expérience utilisateur. C’est pourquoi les applications ajoutent :
Les paquets peuvent être retardés, réordonnés, dupliqués ou perdus. La congestion peut faire bondir la latence. Un serveur peut répondre mais la réponse ne vous parvient jamais. Cela se manifeste par des tests instables, des 504 aléatoires ou « ça marche chez moi ». Souvent, le code est correct — c’est le chemin entre machines qui a un problème.
Les plateformes cloud peuvent sembler un type complètement nouveau d’informatique — bases de données managées, fonctions serverless, « mise à l’échelle infinie ». En dessous, vos requêtes reposent toujours sur les mêmes fondations TCP/IP que Bob Kahn a contribué à initier : IP transporte les paquets entre réseaux, et TCP (ou parfois UDP) forme l’expérience réseau pour les applications.
La virtualisation et les conteneurs changent où le logiciel tourne et comment il est empaqueté :
Mais ce sont des détails de déploiement. Les paquets utilisent toujours l’adressage IP et le routage, et de nombreuses connexions reposent encore sur TCP pour une livraison ordonnée et fiable.
Les architectures cloud courantes sont construites à partir de blocs réseau familiers :
Même quand vous ne « voyez » jamais une adresse IP, la plateforme en alloue, route les paquets et suit les connexions en coulisse.
TCP peut récupérer des paquets perdus, réordonner la livraison et s’ajuster à la congestion — mais il ne peut pas promettre l’impossible. Dans les systèmes cloud, la fiabilité est un effort collectif :
C’est aussi pourquoi les plateformes « vibe‑coding » qui génèrent et déploient des applications full‑stack dépendent des mêmes fondamentaux. Par exemple, Koder.ai peut vous aider à lancer rapidement une app React avec un backend Go et PostgreSQL, mais dès que cette app parle à une API, une base ou un client mobile, vous retombez dans l’univers TCP/IP — connexions, timeouts, retries, et tout le reste.
Quand on parle « réseau », on choisit souvent entre deux transports : TCP et UDP. Les deux reposent sur IP mais font des compromis très différents.
TCP convient quand vous avez besoin que les données arrivent dans l’ordre, sans trou, et que vous préférez attendre plutôt que deviner. Pensez : pages web, appels d’API, transferts de fichiers, connexions de base de données.
C’est pourquoi une grande partie d’Internet quotidien l’utilise — HTTPS s’appuie sur TCP (via TLS) et la plupart des logiciels requête/réponse supposent le comportement de TCP.
Le revers : la fiabilité de TCP peut ajouter de la latence. Si un paquet manque, les paquets suivants peuvent être retardés jusqu’à ce que le trou soit comblé ("head‑of‑line blocking"). Pour les expériences interactives, cette attente peut être pire qu’un défaut occasionnel.
UDP se rapproche d’un « envoie‑et‑espère ». Il n’y a ni ordre intégré, ni réexpédition, ni gestion de congestion au niveau UDP.
Les développeurs choisissent UDP quand le timing compte plus que la perfection, comme pour l’audio/vidéo en direct, les jeux ou la télémétrie en temps réel. Beaucoup de ces applications implémentent leur propre légèreté de fiabilité (ou aucune) selon ce que les utilisateurs remarquent.
Un exemple moderne majeur : QUIC fonctionne sur UDP, permettant des établissements de connexion plus rapides et évitant certains goulots de TCP — sans modifier le réseau IP sous‑jacent.
Choisissez selon :
TCP est souvent qualifié de « fiable », mais cela ne garantit pas que votre application semblera toujours fiable. TCP peut récupérer de nombreux problèmes réseau, mais il ne peut pas garantir faible délai, débit constant ou bonne expérience utilisateur quand le chemin entre deux systèmes est instable.
Perte de paquets force TCP à retransmettre. La fiabilité est préservée, mais les performances peuvent s’effondrer.
Forte latence (long RTT) rend chaque cycle requête/réponse plus lent, même sans pertes.
Bufferbloat survient quand les routeurs ou files d’attente OS retiennent trop de données. TCP voit moins de pertes, mais les utilisateurs subissent d’énormes délais et des interactions « saccadées ».
MTU mal configurée peut provoquer fragmentation ou blackholing (des paquets disparaissent quand ils sont « trop gros »), créant des échecs confus ressemblant à des timeouts aléatoires.
Plutôt qu’une erreur réseau nette, vous verrez souvent :
Ces symptômes sont réels, mais pas toujours causés par votre code. Souvent, TCP fait son travail — retransmettre, réduire la cadence, attendre — pendant que votre horloge applicative continue de tourner.
Commencez par classer : le problème est‑il plutôt lié à la perte, à la latence ou aux changements de chemin ?
Si vous prototypez rapidement (par exemple en développant un service dans Koder.ai et en le déployant avec hébergement et domaines personnalisés), il vaut la peine d’intégrer ces bases d’observabilité dès la phase de planification — car les pannes réseau se manifestent d’abord par des timeouts et des retries, pas par des exceptions propres.
Supposez que les réseaux vont mal se comporter. Utilisez des timeouts, des retries avec backoff exponentiel et rendez les opérations idempotentes pour que les retries ne facturent pas deux fois, ne créent pas en double ou ne corrompent pas l’état.
TCP/IP est un ensemble partagé de règles réseau qui permet à des réseaux différents de s’interconnecter et de transférer des données de manière prévisible.
Cela importe car il rend utilisables pour les logiciels des liaisons hétérogènes et peu fiables (Wi‑Fi, LTE, fibre, satellite) — ainsi les applications peuvent envoyer des octets et attendre des réponses sans connaître les détails physiques du réseau.
Bob Kahn a porté l’idée d’« internetworking » : connecter des réseaux entre eux sans les forcer à partager le même matériel ou design interne.
Avec des collaborateurs (notamment Vint Cerf), il a contribué à la conception qui sépare IP (adressage/acheminement entre réseaux) et TCP (fiabilité pour les applications par-dessus).
La commutation de paquets consiste à découper un message en petits paquets qui peuvent voyager indépendamment.
Avantages :
IP a une seule mission : faire avancer les paquets vers une adresse de destination. Il ne garantit ni la livraison, ni l’ordre, ni le délai.
Ce modèle « au mieux » permet d’évoluer à l’échelle mondiale : les routeurs restent simples et rapides et le réseau continue de fonctionner quand des liens tombent ou que des routes changent.
TCP transforme les paquets « best effort » d’IP en un flux d’octets ordonné utilisable par les applications.
Il le fait grâce à :
Ils résolvent des problèmes différents :
En pratique, de bonnes performances exigent les deux : un émetteur rapide doit respecter le récepteur le réseau.
La mise en couches sépare les responsabilités pour que chaque partie puisse évoluer indépendamment.
Pour les développeurs, cela signifie que vous pouvez construire des API sans repenser l’application pour chaque type de réseau.
Le principe de bout en bout garde le cœur du réseau (les routeurs) relativement simple et place l’intelligence aux extrémités.
Implication pratique : ce sont les applications et les systèmes d’exploitation qui gèrent la fiabilité, les timeouts, les retries et le chiffrement (souvent via TLS), car le réseau ne peut pas adapter son comportement à chaque application.
Latence = temps aller‑retour ; elle pénalise les échanges bavards (beaucoup de petites requêtes, redirections, appels répétés).
Débit = octets par seconde ; il importe pour les gros transferts (images, sauvegardes, vidéo).
Conseils pratiques :
Choisissez selon vos besoins :
Règle : si votre application est demande/réponse et exige la correction, partez de TCP (ou QUIC via HTTP/3).
