# Politique de gestion des versions et de prise en charge Stripe Comprendre la politique de gestion des versions et de prise en charge Stripe. ## Versions de l’API Stripe À partir de la version 2024-09-30.acacia, Stripe suit un [nouveau processus de publication d’API](https://stripe.com/blog/introducing-stripes-new-api-release-process) dans lequel nous publions de nouvelles versions d’API tous les mois sans modification importante. Deux fois par an, nous publions une nouvelle version (par exemple `acacia`) qui commence avec une version de l’API comportant des modifications importantes. Vous pouvez vous attendre à de nouvelles versions mineures des SDK avec chaque version mensuelle de l’API et à de nouvelles versions majeures des SDK avec chaque version majeure publiée deux fois par an. Il peut arriver qu’une mise à jour majeure des SDK coïncide avec les mises à jour mensuelles de version de l’API. Cela se produit lorsque les SDK doivent inclure une modification majeure. La version actuelle de l’API est **2026-03-25.dahlia**. Pour découvrir les changements apportés à toute nouvelle version de l’API, consultez les [modifications de l’API](https://docs.stripe.com/upgrades.md). ### Clés API d’organisation Toutes les requêtes API effectuées à l’aide d’une [clé d’API d’organisation](https://docs.stripe.com/keys.md#organization-api-keys) doivent inclure l’en-tête `Stripe-Version` afin de garantir la cohérence et la prévisibilité des intégrations de votre organisation. ## Versions des SDK Stripe La politique de gestion des versions du SDK de Stripe repose sur la norme de gestion sémantique des versions. Par exemple dans la version 4.3.2, 4 correspond à une modification *majeure*, 3 à une modification *mineure* et 2 à un *correctif*. Quand nous publions une nouvelle version de SDK contenant de nouvelles fonctionnalités ou des corrections de bogues, nous ajoutons 1 à l’un de ces trois composants de version, selon le type de changement introduit. - **Majeur**. Nous changeons le composant de version *majeure* lorsque la version contient des changements importants, non rétrocompatibles avec la version la plus récente : la version ajoute un paramètre obligatoire ou modifie un type, une propriété, une méthode ou un paramètre. Par exemple si la version renomme les classes d’exceptions du SDK. - **Mineur**. Nous changeons le composant de version *mineure* lorsque la version contient de nouvelles fonctionnalités rétrocompatibles avec la version la plus récente : la version ajoute un nouveau type, une nouvelle propriété, une nouvelle méthode, un nouveau paramètre facultatif ou une nouvelle valeur de paramètre prise en charge. Par exemple si la version clarifie le message de suppression des métadonnées du SDK. - **Correctif**. Nous changeons le composant de version *corrective* lorsque la version contient des corrections de bogues rétrocompatibles : la version modifie un comportement, sans changer les types, propriétés, méthodes ou paramètres documentés. Par exemple, la version corrige un bogue à cause duquel les chargements de fichiers n’étaient pas correctement répertoriés. Chaque version du SDK utilise la version de l’API en vigueur au moment de sa publication pour effectuer des requêtes API. Reportez-vous à la [page de gestion des versions](https://docs.stripe.com/api/versioning.md) pour voir comment remplacer cette information. ## Politique de prise en charge des SDK Stripe Les nouvelles fonctionnalités et corrections de bogues sont publiées sur la dernière version *majeure* d’un SDK. Si vous utilisez une ancienne version *majeure* du SDK, nous vous recommandons de passer à la version majeure la plus récente pour bénéficier de ces fonctionnalités et corrections de bogues. Les anciennes versions majeures du paquet restent disponibles, mais ne reçoivent plus aucune mise à jour. ### Guides de migration Nous fournissons des guides de migration pour vous aider à passer d’anciennes versions majeures du SDK. Vous les trouverez dans la section wiki de nos référentiels SDK GitHub. Le même wiki établit également le mappage entre les versions majeures du SDK et les versions de l’API. - [Wiki du SDK Python](https://github.com/stripe/stripe-python/wiki) - [Wiki du SDK .NET](https://github.com/stripe/stripe-dotnet/wiki) - [Wiki du SDK Java](https://github.com/stripe/stripe-java/wiki) - [Wiki du SDK Go](https://github.com/stripe/stripe-go/wiki) - [Wiki du SDK PHP/wiki](https://github.com/stripe/stripe-php/wiki) - [Wiki du SDK Ruby/wiki](https://github.com/stripe/stripe-ruby/wiki) - [Wiki du SDK Node.js](https://github.com/stripe/stripe-node/wiki) ## Politique de prise en charge des versions d’exécution de langage du SDK Stripe Lorsqu’une version d’exécution de langage arrive en fin de vie, nous la marquons comme « obsolète » dans les tableaux ci-dessous et commençons sa période de support étendu. La durée exacte de la période de support étendu varie selon le langage, mais elle est comprise entre 1 et 2 ans. Une fois la période de support prolongé pour une version linguistique terminée, la version majeure suivante du SDK ne prendra plus en charge cette version linguistique. Cependant, les versions précédentes du SDK resteront compatibles avec ces anciennes versions linguistiques. Nous annoncerons à l’avance toutes les dépréciations d’exécution sur cette page, dans le fichier README de chaque SDK et dans le journal des modifications de chaque langue. > Même si un SDK *pourrait* continuer à fonctionner sur une version linguistique non prise en charge, ne continuez pas à l’utiliser. Les SDK qui fonctionnent sur des versions non prises en charge peuvent cesser de fonctionner de manière inattendue dans n’importe quelle version, et la cause de cette panne peut ne pas être mentionnée dans le journal des modifications. ### Politiques linguistiques #### Python La version Python 3.10 arrivera en fin de vie en octobre 2026. Nous continuerons à la prendre en charge pour les versions API de mars et septembre 2027. Nous supprimerons le support pour cette version lors de la sortie de la version majeure de mars 2028. Nous assurons le support de la version *Python 3.9+*. Cela inclut toutes les versions Python qui [bénéficient actuellement d’un support de sécurité](https://endoflife.date/python), ainsi que celles qui sont dans la période de support prolongée. Les versions Python ayant atteint leur date de fin de vie bénéficieront d’une période de support prolongée à *1 an* (deux versions majeures de l’API). Nous supprimerons le support de la version Python la plus ancienne lors de la sortie de la version de mars de l’API chaque année. Voici le calendrier de dépréciation : | Version Python | État | Fin de cycle de vie | abandon du support | Dernier SDK compatible | Notes | | -------------- | -------------------- | ------------------- | ------------------ | ---------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | 3.12 | (pris en charge) | Octobre 2028 | Mars 2030 | À définir | | | 3.11 | (pris en charge) | Octobre 2027 | Mars 2029 | À définir | | | 3.10 | (pris en charge) | Octobre 2026 | Mars 2028 | À définir | | | 3.9 | (obsolète) | Octobre 2025 | Mars 2027 | À définir | | | 3,8 | (non pris en charge) | octobre 2024 | Mars 2026 | `v14.4.1` | La version 3.8 est la première version à ne plus être prise en charge selon le calendrier défini dans cette politique. | | 3,7 | (non pris en charge) | Juin 2023 | Mars 2026 | `v14.4.1` | Afin de faciliter la transition vers cette politique, nous prolongeons la période de support de la version 3.7 afin de donner aux utilisateurs plus de temps pour mettre à jour leurs intégrations. | | 3.6 | (non pris en charge) | décembre 2021 | Septembre 2025 | `v12.5.1` | La décision d’abandonner la version 3.6 est antérieure à cette politique et, par conséquent, ne suit pas le schéma susmentionné. | #### Ruby La version Ruby 3.4 arrivera en fin de vie en mars 2028. Nous continuerons à la prendre en charge pendant 3 versions de l’API (mars 2028, septembre 2028 et mars 2029). Nous cesserons de prendre en charge la version 3.4 lors de la sortie de la version de septembre 2029. Nous prenons en charge la version *Ruby 2.7+*. Cela inclut toutes les versions Ruby qui [bénéficient actuellement d’un support](https://endoflife.date/ruby), ainsi que celles qui se trouvent dans la période de support prolongée. Les versions Ruby ayant atteint leur date de fin de vie bénéficieront d’une période de support prolongée de *1,5 an* (trois versions majeures de l’API). Une fois que nous aurons rattrapé notre retard, nous abandonnerons le support de la version Ruby la plus ancienne prise en charge avec la version de l’API de septembre de chaque année. Voici le calendrier de dépréciation : | Version Ruby | État | Fin de cycle de vie | abandon du support | Dernier SDK compatible | Notes | | ------------ | -------------------- | ------------------- | ------------------ | ---------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | 4,0 | (pris en charge) | Mars 2029 | Septembre 2030 | À définir | | | 3,4 | (pris en charge) | Mars 2028 | Septembre 2029 | À définir | | | 3.3 | (pris en charge) | Mars 2027 | Septembre 2028 | À définir | La version 3.3 est la première version à ne plus être prise en charge selon le calendrier défini dans cette politique. | | 3.2 | (obsolète) | Mars 2026 | Mars 2028 | À définir | Afin de faciliter la transition vers cette politique, nous prolongeons la période de support de la version 3.2 afin de donner aux utilisateurs plus de temps pour mettre à jour leurs intégrations. | | 3.1 | (obsolète) | Mars 2025 | Septembre 2027 | À définir | Afin de faciliter la transition vers cette politique, nous prolongeons la période de support de la version 3.1 afin de donner aux utilisateurs plus de temps pour mettre à jour leurs intégrations. | | 3.0 | (obsolète) | avril 2024 | Mars 2027 | À définir | Afin de faciliter la transition vers cette politique, nous prolongeons la période de support de la version 3.0 afin de donner aux utilisateurs plus de temps pour mettre à jour leurs intégrations. | | 2.7 | (obsolète) | Mars 2023 | Septembre 2026 | À définir | Afin de faciliter la transition vers cette politique, nous prolongeons la période de support de la version 2.7 afin de donner aux utilisateurs plus de temps pour mettre à jour leurs intégrations. | | 2.6 | (non pris en charge) | Mars 2022 | Mars 2026 | `v18.4.2` | Afin de faciliter la transition vers cette politique, nous prolongeons la période de support de la version 2.6 afin de donner aux utilisateurs plus de temps pour mettre à jour leurs intégrations. | | 2.5 | (non pris en charge) | Mars 2021 | Septembre 2025 | `v15.5.0` | La décision d’abandonner la version 2.5 est antérieure à cette politique et, par conséquent, ne suit pas le calendrier susmentionné. | | 2,4 | (non pris en charge) | Mars 2020 | Septembre 2025 | `v15.5.0` | La décision d’abandonner la version 2.4 est antérieure à cette politique et, par conséquent, ne suit pas le calendrier susmentionné. | | 2,3 | (non pris en charge) | Mars 2019 | Septembre 2025 | `v15.5.0` | La décision d’abandonner la version 2.3 est antérieure à cette politique et, par conséquent, ne suit pas le calendrier susmentionné. | #### PHP Nous prenons en charge *PHP 7.2+*. Nous n’avons toujours pas de politique ferme en matière de fin de prise en charge des versions PHP et ne disposons donc pas encore du calendrier que nous pourrions fournir pour toutes les versions futures. Malgré cela, nous annonçons à l’avance certaines fins de prise en charge des versions PHP ayant atteint leur fin de vie depuis longtemps (voir le tableau ci-dessous). Nous prévoyons de continuer à abandonner les versions ayant atteint leur fin de vie. Si vous utilisez une version PHP antérieure à la version 7.4, nous vous recommandons de la mettre à niveau (ou de contacter votre hébergeur mutualisé pour faciliter le processus). Nous mettrons à jour nos recommandations à mesure que la situation évoluera. Voici le calendrier de dépréciation : | Version PHP | État | Fin de cycle de vie | abandon du support | Dernier SDK compatible | | ----------- | -------------------- | ------------------- | --------------------------------------------------------------- | ---------------------- | | 8.2 | (pris en charge) | Décembre 2026 | Aucun plan de fin de prise en charge n’est prévu pour le moment | À définir | | 8.1 | (pris en charge) | Décembre 2025 | Aucun plan de fin de prise en charge n’est prévu pour le moment | À définir | | 8.0 | (pris en charge) | Novembre 2023 | Aucun plan de fin de prise en charge n’est prévu pour le moment | À définir | | 7.4 | (pris en charge) | Novembre 2022 | Aucun plan de fin de prise en charge n’est prévu pour le moment | À définir | | 7.3 | (obsolète) | Novembre 2020 | Probablement septembre 2026 | À définir | | 7.2 | (obsolète) | Décembre 2019 | Probablement septembre 2026 | À définir | | 7.1 | (non pris en charge) | Décembre 2019 | Mars 2026 | `v19.4.1` | | 7.0 | (non pris en charge) | Janvier 2019 | Mars 2026 | `v19.4.1` | | 5.6 | (non pris en charge) | Décembre 2018 | Mars 2026 | `v19.4.1` | #### Go La version Go 1.25 arrivera en fin de vie en août 2026. Nous continuerons à la prendre en charge pour les versions API de septembre 2026 et mars 2027. Nous abandonnerons son support lors de la version majeure de septembre 2027. Nous prenons en charge la version *Go 1.22+*. Cela inclut toutes les versions Go qui [bénéficient actuellement d’un support](https://endoflife.date/go), ainsi que celles qui se trouvent dans la période de support prolongée. Les versions Go ayant atteint leur date de fin de vie bénéficieront d’une période de support prolongée à *1 an* (deux versions majeures de l’API). Une fois que nous aurons rattrapé notre retard, nous abandonnerons le support de la version Go la plus ancienne lors de la sortie de chaque version majeure de l’API. Voici le calendrier de dépréciation : | Version Go | État | Fin de cycle de vie | abandon du support | Dernier SDK compatible | Notes | | ---------- | -------------------- | ------------------- | ------------------ | ---------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | 1,26 | (pris en charge) | Février 2027 | Mars 2028 | À définir | | | 1,25 | (pris en charge) | Août 2026 | Septembre 2027 | À définir | | | 1,24 | (obsolète) | Février 2026 | Mars 2027 | À définir | | | 1.23 | (obsolète) | Août 2025 | Septembre 2026 | À définir | La version 1.23 sera la première version à ne plus être prise en charge, conformément au calendrier prévu. | | 1.22 | (obsolète) | Février 2025 | Septembre 2026 | À définir | Afin de faciliter la transition vers cette politique, nous prolongeons la période de support de la version 1.22 afin de donner aux utilisateurs plus de temps pour mettre à jour leurs intégrations. | | 1.21 | (non pris en charge) | août 2024 | Mars 2026 | `v84.4.1` | Afin de faciliter la transition vers cette politique, nous prolongeons la période de support de la version 1.21 afin de donner aux utilisateurs plus de temps pour mettre à jour leurs intégrations. | | 1.20 | (non pris en charge) | février 2024 | Mars 2026 | `v84.4.1` | Afin de faciliter la transition vers cette politique, nous prolongeons la période de support de la version 1.20 afin de donner aux utilisateurs plus de temps pour mettre à jour leurs intégrations. | | 1.19 | (non pris en charge) | septembre 2023 | Septembre 2025 | `v82.5.1` | La décision d’abandonner la version 1.19 est antérieure à cette politique et, par conséquent, ne suit pas le schéma susmentionné. | | 1.18 | (non pris en charge) | Février 2023 | Septembre 2025 | `v82.5.1` | La décision d’abandonner la version 1.18 est antérieure à cette politique et, par conséquent, ne suit pas le schéma susmentionné. | #### Node.js La version de Node 22 arrivera en fin de vie en avril 2027. Nous continuerons à la prendre en charge pour les versions API de septembre 2027 et mars 2028. Nous cesserons de la prendre en charge lors de la sortie de la version majeure en septembre 2028. Nous assurons le support des versions LTS (numérotées paires) de *Node 18+\**. Cela inclut toutes les versions de Node qui [bénéficient actuellement d’un support](https://endoflife.date/nodejs), ainsi que celles qui se trouvent dans la période de support prolongée. > Le calendrier de publication de Node.js [changera en octobre 2026](https://nodejs.org/en/blog/announcements/evolving-the-nodejs-release-schedule), et ce calendrier sera donc ajusté en conséquence. La durée de la période de support étendu ne changera pas, mais le rythme de dépréciation sera modifié. Les versions de Node.js ayant atteint leur date de fin de vie bénéficieront d’une période de support prolongée d’1 an (deux versions majeures de l’API). Une fois que nous aurons rattrapé notre retard, nous cesserons de prendre en charge la version LTS de Node la plus ancienne prise en charge chaque année lors de la sortie de l’API en septembre. Voici le calendrier de dépréciation : | Version Node | État | Fin de cycle de vie | abandon du support | Dernier SDK compatible | Notes | | ------------ | -------------------- | ------------------- | ------------------ | ---------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | 24 | (pris en charge) | Avril 2028 | Septembre 2029 | À définir | | | 22 | (pris en charge) | Avril 2027 | Septembre 2028 | À définir | | | 20 | (obsolète) | Avril 2026 | Septembre 2027 | À définir | | | 18 | (obsolète) | Avril 2025 | Septembre 2026 | À définir | La version 18 est la première version à ne plus être prise en charge selon le calendrier défini dans cette politique. | | 16 | (non pris en charge) | septembre 2023 | Mars 2026 | `v20.4.1` | Afin de faciliter la transition vers cette politique, nous prolongeons la période de support de la version 16 afin de donner aux utilisateurs plus de temps pour mettre à jour leurs intégrations. | | 14 | (non pris en charge) | Avril 2023 | Septembre 2025 | `v18.5.0` | La décision d’abandonner la version 14 est antérieure à cette politique et, par conséquent, ne suit pas le schéma susmentionné. | | 12 | (non pris en charge) | Avril 2022 | Septembre 2025 | `v18.5.0` | La décision d’abandonner la version 12 est antérieure à cette politique et, par conséquent, ne suit pas le schéma susmentionné. | #### .NET .NET 9.0 arrivera en fin de vie en mai 2026. En tant que version STS, nous abandonnerons son support lors de la prochaine version majeure (septembre 2026). S’il s’agissait d’une version LTS, nous abandonnerons en revanche son support lors de la version API de septembre 2027. Le support de .NET se divise en deux catégories. - Pour .NET Framework, notre service de support couvre *4.6.2+*. - Pour .NET Core, nous prenons en charge *.NET 6+*. Nous assurerons le soutien des versions .NET core selon le calendrier suivant : - Les versions LTS (numéros pairs) sont supportées pendant *1 an* après leur fin de vie (deux versions majeures de l’API). - Les versions STS (numéros impairs) ne sont supportées que tant qu’elles restent la version active. Voici le calendrier de dépréciation : | Version .NET Core | État | Fin de cycle de vie | abandon du support | Dernier SDK compatible | Notes | | ----------------- | -------------------- | ------------------- | ------------------ | ---------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | 10 | (pris en charge) | Novembre 2028 | Mars 2030 | À définir | | | 9 | (pris en charge) | Novembre 2026 | Mars 2027 | À définir | | | 8 | (pris en charge) | Novembre 2026 | Mars 2028 | À définir | La version 8 est la première version à ne plus être prise en charge selon le calendrier défini dans cette politique. | | 7 | (non pris en charge) | mai 2024 | Mars 2026 | `v50.4.1` | Afin de faciliter la transition vers cette politique, nous prolongeons la période de support pour la version 7 afin de donner aux utilisateurs plus de temps pour mettre à jour leurs intégrations. | | 6 | (obsolète) | Nov. 2024 | Septembre 2026 | À définir | Afin de faciliter la transition vers cette politique, nous prolongeons la période de support de la version 6 afin de donner aux utilisateurs plus de temps pour mettre à jour leurs intégrations. | | 5 | (non pris en charge) | Mai 2022 | Mars 2026 | `v50.4.1` | Afin de faciliter la transition vers cette politique, nous prolongeons la période de support de la version 5 afin de donner aux utilisateurs plus de temps pour mettre à jour leurs intégrations. | | 3.1 | (non pris en charge) | Décembre 2022 | Septembre 2025 | `v48.5.0` | La décision d’abandonner la version 3.1 est antérieure à cette politique et, par conséquent, ne suit pas le schéma susmentionné. | #### Java Nous prenons en charge toutes les versions LTS de Java. Il s’agit actuellement des versions Java suivantes : - 25 - 21 - 17 - 11 - 8 (1.8) ## Canal de publication de la version bêta publique Nous avons un [canal de publication de la version bêta publique](https://stripe.dev/blog/introducing-stripes-new-public-preview-release-channel), qui utilise les versions bêta de l’API qui sont distinctes des versions [disponibles au public](https://docs.stripe.com/release-phases.md) (GA). Par exemple, `2025-04-30.preview` au lieu de `2025-04-30.basil`. La version bêta actuelle de l’API est **2026-03-25.preview**. Pour accéder aux nouvelles fonctionnalités et améliorations de la [version bêta](https://docs.stripe.com/release-phases.md), utilisez les versions de nos SDK qui portent le suffixe `beta` ou `b`. Par exemple, `5.1.0b3` en Python et `5.1.0-beta.3` dans les SDK rédigés dans un autre langage. Pour obtenir les instructions d’installation ou des informations sur la transmission des en-têtes de la version bêta publique dans l’en-tête `Stripe-Version`, consultez la section **SDK de la version bêta ** dans les fichiers README disponibles dans les référentiels GitHub correspondants. - [Version bêta publique de SDK Python](https://github.com/stripe/stripe-python/?tab=readme-ov-file#public-preview-sdks) - [Version bêta publique de SDK .NET](https://github.com/stripe/stripe-dotnet?tab=readme-ov-file#public-preview-sdks) - [Version bêta publique de SDK Java](https://github.com/stripe/stripe-java?tab=readme-ov-file#public-preview-sdks) - [Version bêta publique de Go SDK](https://github.com/stripe/stripe-go?tab=readme-ov-file#public-preview-sdks) - [Version bêta publique de SDK PHP](https://github.com/stripe/stripe-php?tab=readme-ov-file#public-preview-sdks) - [Version bêta publique de SDK Ruby](https://github.com/stripe/stripe-ruby?tab=readme-ov-file#public-preview-sdks) - [Version bêta publique de SDK Node.js](https://github.com/stripe/stripe-node?tab=readme-ov-file#public-preview-sdks) ## Canal de diffusion de la version bêta privée Nous publions également des fonctionnalités en [phase de version bêta privée](https://docs.stripe.com/release-phases.md) qui nécessitent un accès sur invitation uniquement. Ces fonctionnalités utilisent également les versions bêta de l’API. Pour accéder aux fonctionnalités et améliorations de la version bêta privée après invitation, utilisez les versions de nos SDK qui ont un suffixe `alpha` ou `a`. Par exemple, `5.1.0a3` dans Python et `5.1.0-alpha.3` dans d’autres SDK linguistiques. Pour obtenir les instructions d’installation ou des informations sur la transmission des en-têtes de la version bêta publique dans l’en-tête `Stripe-Version`, consultez la section **SDK de la version bêta privée** dans les fichiers README disponibles dans les référentiels GitHub correspondants. - [Version bêta privée SDK Python](https://github.com/stripe/stripe-python/?tab=readme-ov-file#private-preview-sdks) - [Version bêta privée du SDK .NET](https://github.com/stripe/stripe-dotnet?tab=readme-ov-file#private-preview-sdks) - [Version bêta privée du SDK Java](https://github.com/stripe/stripe-java?tab=readme-ov-file#private-preview-sdks) - [Version bêta SDK Go](https://github.com/stripe/stripe-go?tab=readme-ov-file#private-preview-sdks) - [Version bêta privée SDK PHP](https://github.com/stripe/stripe-php?tab=readme-ov-file#private-preview-sdks) - [Version bêta privée du SDK Ruby](https://github.com/stripe/stripe-ruby?tab=readme-ov-file#private-preview-sdks) - [Version bêta privée du SDK Node.js](https://github.com/stripe/stripe-node?tab=readme-ov-file#private-preview-sdks) ## See also - [Gérer le contrôle des versions des webhooks](https://docs.stripe.com/webhooks/versioning.md)