L’essor de Let’s Encrypt, depuis 2015, et sa délivrance de certificats gratuits a permis de démocratiser et presque de « banaliser » l’utilisation des certificats TLS. Gratuits, automatisés et faciles à déployer, ces certificats sont devenus, pendant longtemps, une excellente solution pour les startups, les blogs et les petits projets web.
Mais Let’s Encrypt doit aujourd’hui faire face à des exigences plus larges de gestion des identités numériques, de pilotage des risques et de résilience opérationnelle. Dans ce contexte, sa valeur ne se limite plus au certificat lui‑même, mais à l’écosystème qui l’entoure : automatisation maîtrisée, supervision transverse, intégration à des processus de sécurité complexes, capacité à prouver à tout moment qui a délivré quoi, pour quel usage, et dans quel cadre de conformité.
Dans cette perspective, l’adoption de Let’s Encrypt par les moyennes et grandes organisations, pose une interrogation essentielle, non pas, « est ce que cela fonctionne techniquement », mais plutôt : « est-ce que l’usage de ce service gratuit peut rester compatible avec les exigences de gouvernance, de robustesse, de responsabilité et de conformité qui pèsent sur les grandes structures » ? Et la réponse est loin d’être simple : pour y voir plus clair, il est nécessaire de détailler les nombreux « risques et angles morts » auxquels les grandes entreprises vont faire face.
Un service gratuit, mais sans sécurité contractuelle ni d’engagement formalisé
En s’appuyant exclusivement sur Let’s Encrypt, une entreprise ne bénéficie d’aucun engagement de service formalisé, ni de SLA opposable, ni de garantie de support en cas de défaillance ou d’incident majeur.
Autrement dit, la continuité d’activité, la disponibilité des sites critiques ou la capacité à respecter des obligations réglementaires (NIS2, DORA, exigences sectorielles) reposent sur un service qui, par conception, ne fournit pas de cadre contractuel adapté aux enjeux d’un Système d’Information d’entreprise.
Cette absence de filet juridique et opérationnel devient particulièrement problématique lors d’un arrêt de service, d’un bug d’automatisation ou d’un incident de révocation de masse : sans clauses contractuelles sur les délais de rétablissement, les modalités d’escalade ou les pénalités, la responsabilité reste difficile à faire valoir : les impacts business sont donc intégralement portés par l’entreprise utilisatrice.
Pour les organisations qui doivent rendre des comptes à leurs clients, à leurs partenaires ou aux autorités de contrôle, il devient difficile de justifier la dépendance aux certificats Let’s Encrypt, et à un tel niveau d’incertitude…
Durée de vie courte, renouvellements fréquents et risques d’expiration en production
La durée de vie réduite des certificats Let’s Encrypt est de 90 jours seulement et impose un cycle de renouvellement très (trop) fréquent qui augmente mécaniquement le risque d’expiration en production si les processus ne sont pas parfaitement industrialisés.
Chaque point de terminaison TLS devient une source potentielle de défaillance si le renouvellement automatique échoue ou si le déploiement ne se propage pas correctement. Dans les architectures hybrides et multicloud, la combinaison d’une durée de vie très courte des certificats et d’un renouvellement massif automatisé crée une forme de fragilité systémique, particulièrement lorsque des API critiques sont exposées. En outre, si la chaîne de renouvellement est atteinte sur une partie seulement du périmètre, l’incident peut être complexe à diagnostiquer.
Ce modèle devient donc particulièrement problématique dès lors que des flux métiers, des applications clientes ou des intégrations partenaires reposent sur ces certificats : un simple oubli de renouvellement se traduit alors par des erreurs TLS visibles, une rupture de confiance utilisateur, voire une interruption de services contractuellement engagés, amenant perte de revenus et atteinte à la réputation de l’entreprise.
Pour les entreprises, la question n’est donc pas de savoir si l’automatisation fonctionne « en général », mais si elle est suffisamment robuste, supervisée et auditée pour garantir qu’aucun certificat Let’s Encrypt critique ne puisse expirer en production sans alerte préalable, sans procédure de reprise et sans scénario de secours clairement établi.
La limite du « domain validation only » (DV)
Let’s Encrypt ne délivre que des certificats validés par domaine (DV), qui répond au besoin de chiffrer rapidement un site web. Un certificat DV ne garantit que le contrôle technique d’un nom de domaine. Il ne fournit aucune assurance sur l’entité qui se trouve derrière, ni sur sa légitimité juridique, ni sur son niveau de contrôle interne.
S’en remettre exclusivement à des certificats DV revient à considérer que tous les services se valent du point de vue de l’identité, alors que de nombreux cas d’usage (portails de partenaires, espaces clients, interfaces sensibles, API financières ou de santé) exigent au minimum un niveau OV/EV ou des certificats internes permettant de matérialiser la responsabilité de l’organisation.
Pour les entreprises, la généralisation de Let’s Encrypt en DV ne doit donc pas masquer un enjeu clé : le chiffrement ne remplace pas la preuve d’identité, et l’absence de cette preuve peut devenir un problème majeur dans la gestion des risques et la relation de confiance avec clients et partenaires.
La prise en compte du niveau de conformité, audits et exigences réglementaires
Les moyennes et grandes entreprises ont des exigences de sécurité, de conformité, de disponibilité et de gouvernance qui dépassent souvent le cadre d’un simple certificat TLS gratuit.
Dans les secteurs soumis à de fortes contraintes (banque, assurance, santé, opérateurs d’importance vitale), l’usage de Let’s Encrypt ne peut être évalué uniquement sous l’angle technique : il doit être confronté aux exigences de NIS2, DORA et des réglementations sectorielles qui imposent une preuve de maîtrise des services critiques.
Ces textes exigent une traçabilité fine des actifs, une capacité à démontrer la gestion du risque fournisseur, la mise en place de contrôles récurrents et la production de preuves d’audit en cas de contrôle ou d’incident majeur. Or, un service de certificats 100 % gratuit, sans contrat ni SLA ne permet pas de justifier de la continuité des canaux chiffrés, de l’authentification des services exposés ou de la protection des données sensibles, en l’absence de levier contractuel.
Lors d’audits, l’absence d’encadrement formel : sans politiques, sans matrices de criticité et sans contrats complémentaires (Autorité de Certification commerciale ou PKI (Public Key Infrastructure) interne pour les services essentiels), l’organisation expose une dépendance non maîtrisée qui peut être pointée comme non‑conformité.
Que choisir entre gain budgétaire et maîtrise durable des risques numériques ?
Let’s Encrypt est techniquement sûr et répond parfaitement à l’objectif de chiffrer massivement le web à coût nul, mais ne fournit ni cadre contractuel, ni pilotage centralisé, ni accompagnement stratégique pour les environnements critiques. Pour une entreprise, le véritable enjeu consiste à déterminer si l’usage massif de certificats gratuits s’inscrit dans une trajectoire cohérente de maîtrise des risques numériques.
Let’s Encrypt apporte un gain budgétaire immédiat et facilite le chiffrement généralisé, mais la valeur réelle d’une démarche de sécurité réside dans la capacité à assurer la continuité de service, à gérer les incidents et à rendre des comptes aux clients, aux partenaires et aux régulateurs. Un choix purement économique peut ainsi générer, à moyen terme, des coûts cachés : interruptions de production liées à des expirations non détectées, investigations complexes faute de traçabilité, renégociation de contrats après un incident, voire sanctions en cas de non‑conformité.
Conclusion : la sécurité d’entreprise nécessite plus qu’un simple chiffrement gratuit.
Il apparaît clairement que la sécurité des moyennes et grandes entreprises ne peut se limiter à un chiffrement gratuit, aussi robuste soit-il sur le plan cryptographique. Let’s Encrypt joue pleinement son rôle pour généraliser TLS, mais il ne répond pas, à lui seul, aux exigences de pilotage, de responsabilité et de résilience nécessaires pour des services critiques : absence de SLA opposables, support non garanti, périmètre fonctionnel limité aux certificats DV, difficulté à prouver la maîtrise du cycle de vie des certificats face à un auditeur ou à un régulateur…
Lorsque des applications, des API ou des portails clients sont au cœur du business, il est nécessaire de transformer le chiffrement en levier de confiance et non en source de fragilité : la valeur n’est plus seulement dans le certificat, mais dans l’écosystème de garanties, d’outils et de processus qui l’accompagne et sécurise durablement l’activité et les revenus de l’entreprise. Face à ces enjeux, la véritable interrogation n’est donc pas : « Pourquoi payer pour des certificats ? », mais bien : « Pourquoi accepter des risques inutiles lorsque des systèmes critiques pour l’entreprise sont en jeu ? »
Si vous avez des questions sur les certificats, vous pouvez contacter notre équipe Commerciale ou notre équipe Certificats, qui se feront un plaisir de vous venir en aide !
