{"id":23130,"date":"2026-07-03T10:00:00","date_gmt":"2026-07-03T10:00:00","guid":{"rendered":"https:\/\/atiasavocats.com\/?p=23130"},"modified":"2026-06-23T10:38:55","modified_gmt":"2026-06-23T10:38:55","slug":"licences-open-source-entreprise-pieges-2026","status":"publish","type":"post","link":"https:\/\/atiasavocats.com\/en\/licences-open-source-entreprise-pieges-2026\/","title":{"rendered":"Open source en entreprise : les pi\u00e8ges des licenses (GPL, MIT, Apache)"},"content":{"rendered":"


Par\u00a0<\/em>David Joseph Atias<\/em><\/a>, avocat au Barreau de Paris \u00b7\u00a0<\/em>LinkedIn<\/em><\/a>\u00a0\u00b7 Juillet 2026<\/em><\/em><\/p>\n\n\n\n

\n

Les licences open source sont partout. Selon plusieurs \u00e9tudes sectorielles, plus de 90 % des logiciels d’entreprise int\u00e8grent des composants open source. Cette omnipr\u00e9sence est une chance, mais aussi un risque majeur et souvent ignor\u00e9. Une licence mal comprise \u2014 notamment une licence copyleft comme la GPL \u2014 peut contraindre une entreprise \u00e0 publier son code propri\u00e9taire, d\u00e9truisant un avantage concurrentiel. Un composant non conforme peut bloquer une lev\u00e9e de fonds ou une acquisition. Cet article d\u00e9crypte les familles de licences (MIT, Apache, GPL), l’effet de contagion, le cadre juridique et les pi\u00e8ges \u00e0 \u00e9viter pour s\u00e9curiser votre usage de l’open source.<\/p>\n<\/blockquote>\n\n\n\n

SOMMAIRE<\/p>\n\n\n\n

    \n
  1. Pourquoi les licences open source sont strat\u00e9giques en 2026<\/a><\/li>\n\n\n\n
  2. Le cadre juridique applicable<\/a><\/li>\n\n\n\n
  3. Les familles de licences et leurs pi\u00e8ges<\/a><\/li>\n\n\n\n
  4. Tableau de synth\u00e8se des licences<\/a><\/li>\n\n\n\n
  5. Les 5 pi\u00e8ges \u00e0 \u00e9viter<\/a><\/li>\n\n\n\n
  6. Pourquoi faire appel \u00e0 Atias Avocats<\/a><\/li>\n\n\n\n
  7. FAQ \u2014 Questions fr\u00e9quentes<\/a><\/li>\n<\/ol>\n\n\n\n

    1. Pourquoi les licences open source sont strat\u00e9giques en 2026<\/h2>\n\n\n\n

    Les licences open source r\u00e9gissent la quasi-totalit\u00e9 des logiciels modernes. Leur ma\u00eetrise est devenue un enjeu de conformit\u00e9 et de valorisation. Trois dynamiques renforcent leur importance en 2026.<\/p>\n\n\n\n

    1.1 L’omnipr\u00e9sence de l’open source<\/h3>\n\n\n\n

    L’open source n’est plus une niche, c’est le socle du d\u00e9veloppement. Selon plusieurs \u00e9tudes sectorielles, plus de 90 % des bases de code d’entreprise contiennent des composants open source. Un logiciel moderne agr\u00e8ge des centaines de d\u00e9pendances, chacune sous sa propre licence. Cette accumulation cr\u00e9e une complexit\u00e9 juridique majeure. Sans gouvernance, l’entreprise ignore quelles licences elle utilise r\u00e9ellement, et donc \u00e0 quelles obligations elle est soumise.<\/p>\n\n\n\n

    1.2 Le durcissement r\u00e9glementaire (Cyber Resilience Act)<\/h3>\n\n\n\n

    Le cadre r\u00e9glementaire se durcit. Le Cyber Resilience Act (R\u00e8glement UE 2024\/2847, ou CRA) impose de nouvelles obligations de s\u00e9curit\u00e9 aux produits comportant des \u00e9l\u00e9ments num\u00e9riques. Il rend notamment incontournable le SBOM (Software Bill of Materials, la nomenclature logicielle listant tous les composants). Or, ce document expose pr\u00e9cis\u00e9ment les licences utilis\u00e9es. La conformit\u00e9 devient donc une obligation tra\u00e7able, et non plus une simple bonne pratique.<\/p>\n\n\n\n

    1.3 L’enjeu lors des lev\u00e9es de fonds et acquisitions<\/h3>\n\n\n\n

    L’open source est devenu un point d’audit syst\u00e9matique lors des op\u00e9rations financi\u00e8res. En effet, tout investisseur ou acqu\u00e9reur v\u00e9rifie la conformit\u00e9 open source de la cible lors de la due diligence (audit pr\u00e9alable). Un composant copyleft mal g\u00e9r\u00e9 peut r\u00e9v\u00e9ler que le code pr\u00e9tendument propri\u00e9taire ne l’est pas. Cette d\u00e9couverte peut faire chuter la valorisation, voire faire \u00e9chouer l’op\u00e9ration. Pour aller plus loin, consultez nos services en mati\u00e8re de contrats commerciaux et IT<\/strong><\/a>.<\/p>\n\n\n\n

    2. Le cadre juridique applicable<\/h2>\n\n\n\n

    Ces licences ne sont pas un r\u00e9gime \u00e0 part : elles s’inscrivent dans le droit d’auteur. Quatre fondements principaux structurent leur port\u00e9e juridique.<\/p>\n\n\n\n

    2.1 Le droit d’auteur, fondement de la licence (CPI L.111-1)<\/h3>\n\n\n\n

    L’article L.111-1 du Code de la propri\u00e9t\u00e9 intellectuelle (CPI) prot\u00e8ge le logiciel par le droit d’auteur. Une licence open source est donc une autorisation d’usage accord\u00e9e par l’auteur, sous conditions. Le logiciel reste prot\u00e9g\u00e9 : \u00ab open source \u00bb ne signifie pas \u00ab libre de droits \u00bb. L’utilisateur ne peut en user que dans les limites fix\u00e9es par la licence. Hors de ces limites, il commet une contrefa\u00e7on.<\/p>\n\n\n\n

    2.2 La licence comme contrat conditionnel<\/h3>\n\n\n\n

    La licence open source fonctionne comme un contrat aux conditions pr\u00e9cises. Le respect des obligations (mention de l’auteur, partage du code pour le copyleft) conditionne l’autorisation. Si l’utilisateur viole ces conditions, l’autorisation tombe r\u00e9troactivement. Il se retrouve alors en situation de contrefa\u00e7on, sans titre pour utiliser le code. Cette m\u00e9canique conditionnelle est au c\u0153ur de leur port\u00e9e juridique.<\/p>\n\n\n\n

    2.3 La sanction de la contrefa\u00e7on (CPI L.335-2)<\/h3>\n\n\n\n

    L’article L.335-2 du CPI sanctionne la contrefa\u00e7on. Pour une personne physique, les peines atteignent 300 000 euros d’amende et trois ans d’emprisonnement. S’y ajoutent l’action civile en r\u00e9paration, l’injonction de cessation et, surtout, l’obligation de mise en conformit\u00e9. Cette derni\u00e8re peut imposer la publication du code, cons\u00e9quence redout\u00e9e par toute entreprise ayant int\u00e9gr\u00e9 un composant copyleft dans un produit propri\u00e9taire distribu\u00e9.<\/p>\n\n\n\n

    2.4 L’articulation avec le RGPD et l’AI Act<\/h3>\n\n\n\n

    L’open source croise d’autres r\u00e9glementations. Un composant open source qui traite des donn\u00e9es personnelles doit respecter le RGPD (R\u00e8glement UE 2016\/679). De plus, en 2026, de nombreux mod\u00e8les d’IA sont distribu\u00e9s sous licences open source sp\u00e9cifiques. Leur usage doit s’articuler avec le R\u00e8glement UE 2024\/1689 (AI Act) : transparence (article 50), documentation, et obligations selon la classification du syst\u00e8me. Pour aller plus loin, consultez nos services en mati\u00e8re de protection des donn\u00e9es personnelles<\/strong><\/a>.<\/p>\n\n\n\n

    3. Les familles de licences et leurs pi\u00e8ges<\/h2>\n\n\n\n

    Comprendre les familles de licences libres est la base de toute gouvernance. Chaque famille impose des obligations diff\u00e9rentes, avec des cons\u00e9quences tr\u00e8s variables sur le code de l’entreprise.<\/p>\n\n\n\n

    3.1 Les licences permissives (MIT, BSD)<\/h3>\n\n\n\n

    Les licences permissives sont les plus souples. La licence MIT et les licences BSD autorisent presque tout : usage, modification, int\u00e9gration dans un logiciel propri\u00e9taire, redistribution. La seule obligation est de conserver la mention de droit d’auteur et le texte de la licence. Elles n’imposent aucun partage du code d\u00e9riv\u00e9. Ce sont les licences les plus s\u00fbres pour une entreprise d\u00e9veloppant un produit propri\u00e9taire.<\/p>\n\n\n\n

    3.2 La licence Apache 2.0 et la clause de brevet<\/h3>\n\n\n\n

    La licence Apache 2.0 est permissive, mais ajoute une dimension importante : une concession de brevet explicite. Les contributeurs accordent une licence sur leurs brevets, ce qui s\u00e9curise l’utilisateur contre certaines actions en contrefa\u00e7on de brevet. Elle impose aussi de documenter les modifications. C’est une licence tr\u00e8s utilis\u00e9e et appr\u00e9ci\u00e9e des entreprises, car elle combine souplesse et protection sur le terrain des brevets.<\/p>\n\n\n\n

    3.3 Les licences copyleft fort (GPL)<\/h3>\n\n\n\n

    La GPL (General Public License) est la licence copyleft embl\u00e9matique. Elle impose la r\u00e9ciprocit\u00e9 : tout logiciel distribu\u00e9 qui int\u00e8gre du code GPL doit \u00eatre publi\u00e9 sous GPL, code source compris. C’est l’effet de contagion. Une entreprise qui distribue un produit propri\u00e9taire contenant du code GPL peut \u00eatre contrainte d’ouvrir l’ensemble. La GPL ne se d\u00e9clenche toutefois qu’en cas de distribution : l’usage purement interne \u00e9chappe \u00e0 l’obligation de partage.<\/p>\n\n\n\n

    3.4 La licence AGPL et le pi\u00e8ge du SaaS<\/h3>\n\n\n\n

    La licence AGPL (Affero GPL) est la plus contraignante. Elle comble la \u00ab faille SaaS \u00bb de la GPL : l’obligation de partage se d\u00e9clenche d\u00e8s la mise \u00e0 disposition du logiciel via un r\u00e9seau, m\u00eame sans distribution physique. Un \u00e9diteur SaaS qui utilise un composant AGPL doit donc publier son code, m\u00eame s’il ne distribue jamais le logiciel. C’est l’un des pi\u00e8ges les plus redoutables pour un mod\u00e8le SaaS.<\/p>\n\n\n\n

    3.5 Le copyleft faible (LGPL, MPL)<\/h3>\n\n\n\n

    Entre les deux extr\u00eames, le copyleft faible offre un compromis. La LGPL (Lesser GPL) et la MPL (Mozilla Public License) imposent le partage des modifications du composant lui-m\u00eame, mais pas du logiciel qui l’utilise. Une entreprise peut donc int\u00e9grer un composant LGPL dans un produit propri\u00e9taire, \u00e0 condition de partager les modifications apport\u00e9es au composant. C’est un \u00e9quilibre appr\u00e9ci\u00e9 pour les biblioth\u00e8ques.<\/p>\n\n\n\n

    4. Tableau de synth\u00e8se des licences<\/h2>\n\n\n\n

    Le tableau ci-dessous synth\u00e9tise les principales licences libres, leur type et leur niveau de risque pour une entreprise d\u00e9veloppant un produit propri\u00e9taire.<\/p>\n\n\n\n

    Licence<\/th>Type<\/th>Risque contagion<\/th><\/tr><\/thead>
    MIT, BSD<\/td>Permissive<\/td>\ud83d\udfe1 Faible<\/td><\/tr>
    Apache 2.0<\/td>Permissive + brevet<\/td>\ud83d\udfe1 Faible<\/td><\/tr>
    LGPL, MPL<\/td>Copyleft faible<\/td>\ud83d\udfe0 Mod\u00e9r\u00e9<\/td><\/tr>
    GPL v2 \/ v3<\/td>Copyleft fort<\/td>\ud83d\udd34 \u00c9lev\u00e9 (si distribution)<\/td><\/tr>
    AGPL<\/td>Copyleft r\u00e9seau<\/td>\ud83d\udd34 Critique (m\u00eame en SaaS)<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n

    5. Les 5 pi\u00e8ges \u00e0 \u00e9viter<\/h2>\n\n\n\n

    Au-del\u00e0 des familles de licences, plusieurs pi\u00e8ges r\u00e9currents exposent les entreprises. Les identifier permet d’\u00e9viter la contrefa\u00e7on et la perte de contr\u00f4le sur son code.<\/p>\n\n\n\n

    5.1 Ignorer les d\u00e9pendances transitives<\/h3>\n\n\n\n

    Le premier pi\u00e8ge est l’angle mort des d\u00e9pendances. Un composant que l’on int\u00e8gre en attire souvent d’autres (les d\u00e9pendances transitives), chacune avec sa propre licence. Une biblioth\u00e8que permissive peut ainsi embarquer, en cascade, un composant copyleft. Sans analyse compl\u00e8te de l’arbre des d\u00e9pendances, l’entreprise ignore les licences qu’elle utilise r\u00e9ellement. Un outil d’analyse automatique est indispensable pour cartographier l’ensemble.<\/p>\n\n\n\n

    5.2 Confondre usage interne et distribution<\/h3>\n\n\n\n

    Le deuxi\u00e8me pi\u00e8ge est une erreur d’analyse fr\u00e9quente. L’obligation de partage de la GPL se d\u00e9clenche \u00e0 la distribution, pas \u00e0 l’usage interne. Mais cette fronti\u00e8re est subtile. Fournir un logiciel \u00e0 une filiale, le d\u00e9ployer chez un client, ou l’exposer en SaaS (avec une licence AGPL) peut constituer une distribution d\u00e9clenchant l’obligation. Une analyse pr\u00e9cise du mode de mise \u00e0 disposition est n\u00e9cessaire pour \u00e9valuer le risque r\u00e9el.<\/p>\n\n\n\n

    5.3 N\u00e9gliger l’incompatibilit\u00e9 entre licences<\/h3>\n\n\n\n

    Le troisi\u00e8me pi\u00e8ge est l’incompatibilit\u00e9. Toutes les licences open source ne sont pas combinables entre elles. Par exemple, certaines licences sont incompatibles avec la GPL, ce qui interdit de les m\u00e9langer dans un m\u00eame logiciel distribu\u00e9. Combiner des composants aux licences incompatibles cr\u00e9e un produit juridiquement impossible \u00e0 distribuer l\u00e9galement. La v\u00e9rification de compatibilit\u00e9 est une \u00e9tape essentielle de toute int\u00e9gration.<\/p>\n\n\n\n

    5.4 Omettre les obligations d’attribution<\/h3>\n\n\n\n

    Le quatri\u00e8me pi\u00e8ge touche m\u00eame les licences permissives. La licence MIT et la licence Apache imposent de conserver la mention de droit d’auteur et le texte de la licence. Beaucoup d’entreprises l’oublient, supprimant les en-t\u00eates lors du nettoyage du code. Cet oubli, en apparence mineur, constitue une violation de la licence et donc une contrefa\u00e7on. Le respect scrupuleux des obligations d’attribution est imp\u00e9ratif, m\u00eame pour les licences les plus souples.<\/p>\n\n\n\n

    5.5 Sous-estimer l’open source dans les mod\u00e8les d’IA<\/h3>\n\n\n\n

    Le cinqui\u00e8me pi\u00e8ge, sp\u00e9cifique \u00e0 2026, concerne l’IA. De nombreux mod\u00e8les d’IA sont diffus\u00e9s sous des licences sp\u00e9cifiques, parfois improprement qualifi\u00e9es d’open source, qui restreignent l’usage commercial. Int\u00e9grer un tel mod\u00e8le sans v\u00e9rifier sa licence expose \u00e0 des litiges. De plus, l’articulation avec l’AI Act (R\u00e8glement UE 2024\/1689) impose des obligations de transparence. La v\u00e9rification des licences des mod\u00e8les d’IA est devenue un point de vigilance critique.<\/p>\n\n\n\n

    6. Pourquoi faire appel \u00e0 Atias Avocats<\/h2>\n\n\n\n

    Ma\u00eetriser les licences open source exige une combinaison rare de comp\u00e9tences : expertise de la propri\u00e9t\u00e9 intellectuelle et du droit d’auteur logiciel (CPI L.111-1, L.335-2), connaissance fine des familles de licences et de leurs interactions (permissive, copyleft, compatibilit\u00e9), compr\u00e9hension technique des modes d’int\u00e9gration (liaison statique, dynamique, d\u00e9pendances transitives), et ma\u00eetrise des r\u00e9glementations connexes (Cyber Resilience Act, RGPD, AI Act). Cette double culture juridique et technique est pr\u00e9cis\u00e9ment la valeur ajout\u00e9e d’un cabinet sp\u00e9cialis\u00e9 en contrats IT et droit du num\u00e9rique.<\/p>\n\n\n\n

    Atias Avocats accompagne \u00e9diteurs, startups, scale-ups, ESN (entreprises de services du num\u00e9rique), investisseurs et grands groupes sur l’ensemble du sujet : r\u00e9daction d’une politique open source interne, audit de conformit\u00e9 d’un produit logiciel, analyse du SBOM et identification des licences \u00e0 risque, plan de rem\u00e9diation, accompagnement en due diligence d’acquisition, articulation avec le Cyber Resilience Act et l’AI Act, d\u00e9fense en cas de litige de contrefa\u00e7on. Pour aller plus loin, consultez nos services en mati\u00e8re de contrats commerciaux et IT<\/strong><\/a>.<\/p>\n\n\n\n

    Conclusion<\/h2>\n\n\n\n

    L’open source est une formidable opportunit\u00e9, mais ses licences sont un champ de mines pour qui les ignore. La distinction entre permissive et copyleft, l’effet de contagion de la GPL, le pi\u00e8ge SaaS de l’AGPL, les d\u00e9pendances transitives : autant de risques qui peuvent contraindre une entreprise \u00e0 ouvrir son code ou bloquer une op\u00e9ration financi\u00e8re. Les familles de licences pr\u00e9sent\u00e9es ici, combin\u00e9es \u00e0 la vigilance sur les cinq pi\u00e8ges classiques, offrent un r\u00e9f\u00e9rentiel directement utilisable par CTO, directions des syst\u00e8mes d’information, responsables juridiques et fondateurs.<\/p>\n\n\n\n

    L’investissement requis pour s\u00e9curiser cet usage est sans commune mesure avec le co\u00fbt d’une contrefa\u00e7on ou d’une lev\u00e9e de fonds compromise. \u00c0 l’heure du Cyber Resilience Act et de l’IA open source, la gouvernance de l’open source n’est plus optionnelle. Le r\u00e9flexe \u00e0 adopter est clair : inventorier les composants, \u00e9tablir un SBOM, d\u00e9finir une politique de licences, v\u00e9rifier la compatibilit\u00e9, respecter les attributions, anticiper l’IA. C’est pr\u00e9cis\u00e9ment cette discipline qui transforme l’open source en atout ma\u00eetris\u00e9 plut\u00f4t qu’en risque juridique cach\u00e9.<\/p>\n\n\n\n

    FAQ \u2014 Questions fr\u00e9quentes<\/h2>\n\n\n\n

    Quelle est la diff\u00e9rence entre une licence permissive et une licence copyleft ?<\/h3>\n\n\n\n

    C’est la distinction fondamentale des licences open source. Une licence permissive (MIT, Apache 2.0, BSD) autorise un usage tr\u00e8s large, y compris l’int\u00e9gration dans un logiciel propri\u00e9taire, \u00e0 condition de conserver la mention de droit d’auteur et l’avis de licence. Elle n’impose pas de partager le code d\u00e9riv\u00e9. Une licence copyleft (GPL, AGPL, LGPL) impose au contraire une r\u00e9ciprocit\u00e9 : tout logiciel qui int\u00e8gre du code copyleft et qui est distribu\u00e9 doit lui-m\u00eame \u00eatre publi\u00e9 sous la m\u00eame licence, code source inclus. C’est l’effet de contagion, parfois appel\u00e9 effet viral. Une entreprise qui int\u00e8gre un composant GPL dans son produit propri\u00e9taire et le distribue peut donc \u00eatre contrainte d’ouvrir son propre code. Comprendre cette diff\u00e9rence est la base de toute gouvernance des licences open source.<\/p>\n\n\n\n

    Une licence GPL oblige-t-elle \u00e0 ouvrir tout mon code ?<\/h3>\n\n\n\n

    Pas syst\u00e9matiquement, mais le risque est r\u00e9el et d\u00e9pend de deux facteurs : la distribution et l’int\u00e9gration. La GPL (General Public License) d\u00e9clenche son obligation de partage uniquement en cas de distribution du logiciel \u00e0 des tiers. Un usage purement interne, sans distribution, n’oblige pas \u00e0 publier le code. Mais attention : la licence AGPL (Affero GPL) \u00e9tend cette obligation \u00e0 la simple mise \u00e0 disposition via un r\u00e9seau (un service SaaS), m\u00eame sans distribution physique. Par ailleurs, l’\u00e9tendue de la contagion d\u00e9pend du mode d’int\u00e9gration (liaison statique, dynamique, simple appel). Ces questions sont techniquement et juridiquement complexes. Une mauvaise analyse des licences open source peut contraindre une entreprise \u00e0 publier un code qu’elle pensait propri\u00e9taire, d\u00e9truisant un avantage concurrentiel.<\/p>\n\n\n\n

    Que risque une entreprise qui ne respecte pas une licence open source ?<\/h3>\n\n\n\n

    Le non-respect d’une licence open source est une contrefa\u00e7on. En effet, la licence est la condition de l’autorisation d’usage : si ses conditions ne sont pas respect\u00e9es, l’utilisateur perd son droit et viole le droit d’auteur du contributeur (article L.335-2 du Code de la propri\u00e9t\u00e9 intellectuelle). Les risques sont multiples : action en contrefa\u00e7on (jusqu’\u00e0 300 000 euros d’amende et trois ans d’emprisonnement pour les personnes physiques), injonction de cessation, obligation de mise en conformit\u00e9 (parfois la publication forc\u00e9e du code), dommages-int\u00e9r\u00eats. S’y ajoutent des risques business : blocage d’une acquisition lors d’un audit de due diligence, perte de confiance des clients, atteinte \u00e0 la valorisation. La conformit\u00e9 aux licences open source est donc un enjeu juridique et financier majeur.<\/p>\n\n\n\n

    Comment mettre en place une gouvernance open source ?<\/h3>\n\n\n\n

    Une gouvernance efficace repose sur plusieurs piliers. D’abord, une politique open source interne qui d\u00e9finit les licences autoris\u00e9es, tol\u00e9r\u00e9es et interdites selon les usages. Ensuite, un inventaire des composants utilis\u00e9s, id\u00e9alement formalis\u00e9 dans un SBOM (Software Bill of Materials, la nomenclature logicielle qui liste tous les composants et leurs licences). De plus, des outils d’analyse automatique (Software Composition Analysis) qui scannent le code et d\u00e9tectent les licences. Par ailleurs, un processus de validation avant l’int\u00e9gration de tout nouveau composant. Enfin, une sensibilisation des \u00e9quipes de d\u00e9veloppement. Cette gouvernance des licences open source pr\u00e9vient les risques de contagion et de contrefa\u00e7on, et facilite les audits lors des lev\u00e9es de fonds ou des acquisitions. Elle est devenue indispensable avec le Cyber Resilience Act.<\/p>\n\n\n\n


    Contact :     david@atiasavocats.com<\/a> | LinkedIn: David Joseph Atias<\/em><\/a> | https:\/\/www.atiasavocats.com<\/a> | 42 rue de la Clef, 75005 Paris<\/p>\n\n\n\n

    Atias Avocats \u2014 Contrats IT, Open source, Propri\u00e9t\u00e9 intellectuelle, Compliance<\/em><\/p>","protected":false},"excerpt":{"rendered":"

    Par\u00a0David Joseph Atias, avocat au Barreau de Paris \u00b7\u00a0LinkedIn\u00a0\u00b7 Juillet 2026 Les licences open source sont partout. Selon plusieurs \u00e9tudes sectorielles, plus de 90 % des logiciels d’entreprise int\u00e8grent des…<\/p>","protected":false},"author":1,"featured_media":23131,"comment_status":"closed","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"om_disable_all_campaigns":false,"_monsterinsights_skip_tracking":false,"_monsterinsights_sitenote_active":false,"_monsterinsights_sitenote_note":"","_monsterinsights_sitenote_category":0,"footnotes":""},"categories":[1],"tags":[],"class_list":["post-23130","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-uncategorized"],"_links":{"self":[{"href":"https:\/\/atiasavocats.com\/en\/wp-json\/wp\/v2\/posts\/23130","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/atiasavocats.com\/en\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/atiasavocats.com\/en\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/atiasavocats.com\/en\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/atiasavocats.com\/en\/wp-json\/wp\/v2\/comments?post=23130"}],"version-history":[{"count":1,"href":"https:\/\/atiasavocats.com\/en\/wp-json\/wp\/v2\/posts\/23130\/revisions"}],"predecessor-version":[{"id":23132,"href":"https:\/\/atiasavocats.com\/en\/wp-json\/wp\/v2\/posts\/23130\/revisions\/23132"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/atiasavocats.com\/en\/wp-json\/wp\/v2\/media\/23131"}],"wp:attachment":[{"href":"https:\/\/atiasavocats.com\/en\/wp-json\/wp\/v2\/media?parent=23130"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/atiasavocats.com\/en\/wp-json\/wp\/v2\/categories?post=23130"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/atiasavocats.com\/en\/wp-json\/wp\/v2\/tags?post=23130"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}