Deux bibliothèques, deux missions différentes
Presque tous les développeurs Delphi ont utilisé Indy à un moment ou un autre. Il est fourni avec l'IDE, existe depuis la fin des années 1990, et toute une génération de code réseau Delphi est bâtie sur TIdHTTP, TIdTCPClient, TIdSMTP et compagnie. sgcWebSockets est une bibliothèque commerciale bien plus récente, axée sur les protocoles apparus depuis la conception initiale d'Indy — WebSocket, HTTP/2, HTTP/3 / QUIC, MQTT 5, AMQP 1.0, SSE, WAMP, WebRTC, MCP — ainsi qu'un vaste catalogue d'intégrations d'API REST.
La question la plus fréquente sur les forums Embarcadero et Stack Overflow est une variation de « Pourquoi payer pour sgcWebSockets alors qu'Indy est gratuit ? ». La réponse courte est qu'ils résolvent des problèmes différents, et dans de nombreux projets réels vous finirez par utiliser les deux. Cet article passe en revue les différences pratiques en 2026 pour vous aider à choisir lequel (ou quelle combinaison) convient à votre application.
Ce que fait réellement chaque bibliothèque
Indy est une boîte à outils TCP/UDP polyvalente avec une longue liste de protocoles Internet classiques : HTTP/1.1, FTP, SMTP, POP3, IMAP, NNTP, DNS, IRC, Telnet, Whois, plus un framework de serveur TCP. Sa conception repose sur un modèle thread-par-connexion et des E/S bloquantes. Il n'y a aucun client ou serveur WebSocket natif dans Indy standard — vous devez en greffer un, et plusieurs projets communautaires le font avec des résultats inégaux.
sgcWebSockets est une bibliothèque ciblée et riche en protocoles, conçue pour les scénarios client/serveur modernes. Elle s'organise autour d'un duo central TsgcWebSocketClient / TsgcWebSocketHTTPServer avec des extensions optionnelles pour HTTP/2, HTTP/3 sur QUIC, MQTT, AMQP, STOMP, SSE, WAMP, P2P/WebRTC, IoT (CoAP, AWS IoT, Azure IoT), chiffrement de bout en bout, et plus de 30 wrappers d'API (OpenAI, Anthropic, Google, AWS, Azure, Binance, Coinbase, Kraken, Telegram, WhatsApp, etc.).
Un détail important et souvent négligé : sgcWebSockets utilise Indy en interne comme l'un de ses backends de transport. La plomberie TCP/TLS de plusieurs composants repose sur un TIdTCPClient / TIdHTTPServer Indy sous le capot, donc installer sgcWebSockets ne remplace pas Indy — il s'appuie dessus. La bibliothèque propose aussi des transports alternatifs (style Synapse, ICS, SChannel) pour les scénarios où Indy n'est pas le meilleur choix.
Comparaison fonctionnalité par fonctionnalité
| Fonctionnalité | Indy (standard) | sgcWebSockets |
|---|---|---|
| Client HTTP/1.1 | Oui (TIdHTTP) | Oui (TsgcHTTPComponentClient, peut utiliser le backend Indy ou ICS) |
| Serveur HTTP/1.1 | Oui (TIdHTTPServer) | Oui (TsgcWebSocketHTTPServer, gère HTTP + WS sur le même port) |
| Client/serveur WebSocket | Pas de support natif | RFC 6455 complet, permessage-deflate, sous-protocoles, testé Autobahn |
| HTTP/2 (h2 + h2c) | Non | Oui, HPACK + couche de frames personnalisés |
| HTTP/3 / QUIC | Non | Oui (basé sur msquic) |
| MQTT 3.1.1 et 5.0 | Non | Oui, client et broker |
| AMQP 1.0 / 0.9.1 | Non | Oui |
| STOMP, SSE, WAMP | Non | Oui |
| WebRTC / P2P / STUN / TURN | Non | Oui |
| CoAP et IoT cloud (AWS, Azure) | Non | Oui |
| OpenAI, Anthropic, Gemini, MCP | Non | Oui, composants dédiés |
| FTP / SMTP / POP3 / IMAP | Oui | Non (utilisez Indy pour cela) |
| Gratuit / commercial | Gratuit, style MIT | Commercial, plusieurs éditions dont Free |
| Versions Delphi | D7 et plus (varie selon le fork) | D7 à D13 |
| Maintenance active | Communauté (IndyProject sur GitHub) | Éditeur, releases mensuelles |
Où Indy reste le meilleur choix
Si votre projet est un client Internet classique — télécharger un fichier en HTTP, poster un formulaire, envoyer un e-mail SMTP, récupérer du courrier en IMAP, dialoguer avec un vieux serveur FTP — Indy standard est la bonne réponse. Il est gratuit, livré avec l'IDE, l'API est familière, et vous n'avez besoin de rien d'autre. Il en va de même pour les serveurs TCP amateurs et les protocoles qu'Indy gère nativement (NNTP, IRC, Telnet, Whois). Pour ces cas d'usage, ajouter une bibliothèque payante est superflu.
Indy est aussi le choix évident lorsque vous devez interopérer avec du code utilisant déjà des types Indy — par exemple, des composants attendant un TIdSSLIOHandlerSocketOpenSSL ou un TIdHTTPServerCommandHandler.
Où sgcWebSockets est l'outil approprié
Tout ce qui touche à la pile web moderne est nettement plus simple avec sgcWebSockets. Concrètement :
- WebSocket — la messagerie full-duplex est une fonctionnalité de premier ordre. Le serveur gère HTTP et WebSocket sur le même port, gère les sous-protocoles, supporte la compression, et s'intègre avec le WatchDog de reconnexion automatique dès l'installation.
- HTTP/2 et HTTP/3 — requis pour Apple Push Notifications, les services Google, et un nombre croissant d'API REST qui ont commencé à imposer h2 minimum. Indy n'a aucune réponse ici.
- Brokers de messagerie — MQTT 5, AMQP 1.0, STOMP, WAMP et SSE sont tous livrés comme composants prêts à l'emploi avec TLS, reconnexion et authentification.
- Multimédia temps réel — WebRTC, ICE, STUN, TURN et DTLS-SRTP pour de l'audio/vidéo compatible navigateur et des canaux de données.
- API IA et cloud — OpenAI, Anthropic, Google Gemini, AWS, Azure, Telegram, WhatsApp, Stripe et plusieurs douzaines d'autres sont encapsulés en composants typés plutôt que sous forme d'appels REST bruts.
Performance et passage à l'échelle
Le modèle thread-par-connexion d'Indy est simple et correct, mais il plafonne le débit pratique autour de quelques milliers de connexions concurrentes sur un serveur Windows typique avant que le changement de contexte ne devienne le goulot d'étranglement. sgcWebSockets propose le même backend Indy pour la compatibilité, plus un transport serveur basé sur IOCP sous Windows qui a été mesuré à des dizaines de milliers de connexions WebSocket concurrentes par processus. Pour le débit HTTP pur la différence est plus faible, mais pour les connexions longue durée (WebSocket, MQTT, SSE) l'écart architectural compte.
L'empreinte mémoire par connexion inactive est aussi plus faible avec le transport IOCP car il n'y a pas de thread OS dédié par socket. Sous Linux le tableau est similaire avec des serveurs basés sur epoll via le fork d'Indy fourni par sgcWebSockets.
Maintenance et cadence des releases
Indy est maintenu par un petit groupe de bénévoles sur le dépôt GitHub IndyProject. Les releases sont lentes mais la base de code est stable. Les correctifs critiques (compatibilité TLS, bindings OpenSSL modernes) arrivent mais pas toujours rapidement.
sgcWebSockets est un produit commercial d'eSeGeCe avec des releases mensuelles, un fichier d'historique public et un support éditeur direct. Les nouvelles versions de Delphi sont typiquement supportées dès le premier jour — Delphi 13 a été supporté dès la première bêta — et les nouvelles révisions de protocoles (MQTT 5.0.1, HTTP/3 final, mises à jour de la spec MCP) arrivent en jours plutôt qu'en années.
Licence et tarification
Indy est gratuit et livré avec Delphi. sgcWebSockets est commercial mais propose une Édition Free pour usage non commercial, plus des éditions payantes (Standard, Professional, Enterprise, All-Access) avec une couverture de protocoles progressivement plus large. La plupart des projets commerciaux peuvent justifier une licence Professional mono-développeur avec un seul client déployé.
Une règle de décision simple
Une règle empirique pragmatique en 2026 :
- Utilisez Indy pour SMTP/POP3/IMAP/FTP, pour les téléchargements HTTP courts dans une base de code Indy existante, ou pour tout protocole Internet classique qu'Indy gère déjà nativement.
- Utilisez sgcWebSockets dès que WebSocket, HTTP/2, HTTP/3, MQTT, AMQP, WebRTC, IoT ou toute API IA/REST entre en jeu, ou lorsque vous avez besoin d'un serveur qui passe à l'échelle au-delà de quelques milliers de connexions.
- Utilisez les deux dans le même projet — c'est en fait le pattern le plus courant. Indy reste pour la couche e-mail et FTP, sgcWebSockets gère la couche temps réel et API modernes, et ils partagent la même infrastructure Indy SSL/IO en dessous.
Pour conclure
Indy ne va nulle part — c'est le marteau fidèle dans toute caisse à outils Delphi. Mais les protocoles qui définissent l'internet de 2026 (WebSocket, HTTP/2/3, MQTT, WebRTC, API IA) n'existaient tout simplement pas quand Indy a été conçu. sgcWebSockets comble ce vide avec une bibliothèque ciblée, activement maintenue, supportée commercialement, qui s'appuie sur Indy là où c'est utile et le remplace là où c'est nécessaire. Pour les nouveaux projets ciblant des back-ends modernes, la question n'est plus Indy ou sgcWebSockets ? — c'est comment les combiner ?