# Conception d’API — Cycle de productisation des API

Canonical page: https://apiopscycles.com/fr/cycles/api-productization-cycle/stations/api-design

Language: fr

Entity ID: api-design

Cycle: [Cycle de productisation des API](https://apiopscycles.com/fr/cycles/api-productization-cycle.md)

Read [shared station guidance](https://apiopscycles.com/fr/stations/api-design.md) first. The sections below supplement or replace the corresponding shared sections for this cycle. Sections not repeated here retain the shared guidance.

## Journey entry criteria

- La capacité répond à un besoin métier clair et peut être réutilisée par les utilisateurs prévus. — The API meets a clear business need and is reusable for multiple API consumers. (ID: api-reusability)
- L’interface choisie fournit une abstraction appropriée aux utilisateurs. — The API is intended to shield consumers from backend complexity and inconsistencies. (ID: hide-backend-discrepancies)
- La proposition de valeur de la capacité a été validée avec les parties prenantes métier et utilisateurs. — The API value proposition has been reviewed and validated with the relevant business and consumer stakeholders. (ID: value-prop-validated)
- Les segments d'utilisateurs sont identifiés. — API consumer segments (internal and external) are identified. (ID: consumer-segments-identified)
- Une feuille de route de haut niveau pour la mise en œuvre est définie. — High-level roadmaps for API development are established. (ID: api-roadmap-defined)

## Journey exit criteria

- L'architecture, la plateforme et le mode de mise en œuvre choisis ont été validés avec les parties prenantes concernées en architecture, sécurité et plateforme. — The chosen API architecture and platform patterns have been validated with the relevant architecture, security, and platform stakeholders. (ID: architecture-patterns-validated)
- L’interface choisie fournit une abstraction appropriée aux utilisateurs. — The API is intended to shield consumers from backend complexity and inconsistencies. (ID: hide-backend-discrepancies)
- La conception de l'interface et les capacités exposées sont clairement reliées à la valeur métier et aux besoins des utilisateurs. — The API design and exposed capabilities clearly trace back to business value and user needs. (ID: design-reflects-business-value)
- La conception de l'interface respecte les standards partagés de produit, de conception et de qualité. — The API design follows our shared API product and design conventions. (ID: api-consistency)

## Description

Créer des architectures d'API cohérentes, réutilisables et fondées sur les objectifs métier et des normes communes.

## Why it matters

La conception d'API ne se limite pas à nommer des points de terminaison. Une bonne conception garantit que les API sont utilisables, cohérentes et alignées sur les objectifs métier et techniques. Une mauvaise conception entraîne un couplage étroit, une faible réutilisation et des retouches coûteuses entre les équipes.

## Apply in work

Fournir des modèles de conception réutilisables, des normes communes et des outils de validation pour les spécifications d'API. S'assurer que les décisions de conception sont cohérentes, examinées dès le début et alignées sur les objectifs métier.

## Outcomes

- Des conceptions d'API bien documentées et cohérentes
- Contrats d'interface API réutilisables et validés
- Conceptions alignées sur les modèles de domaine et les modèles d'interaction
- Traçabilité de la conception à la valeur métier

## Steps

1. Définir les entités de base, leurs attributs et leurs relations afin de créer une compréhension conceptuelle partagée entre les API.
2. Utilisez le canevas d'interaction pour définir la manière dont les utilisateurs interagiront avec l'API, en veillant à ce qu'elle réponde à leurs besoins et à leurs attentes.
3. Appliquer les modèles de conception REST pour créer des contrats d'interface cohérents et réutilisables qui sont validés avec les parties prenantes.
4. Appliquer des modèles de conception orientés événements pour créer des contrats d'interface cohérents et réutilisables qui sont validés avec les parties prenantes.
5. Appliquer les modèles de conception GraphQL pour créer des contrats d'interface cohérents et réutilisables qui sont validés avec les parties prenantes.
6. Utiliser les principes de conception et le guide de style des API pour aligner vos décisions de conception sur des règles communes et permettre une validation d'audit cohérente.
7. Appliquez des approches « contract-first » ou « design-first » pour définir et valider le contrat d'interface API avant sa mise en œuvre.
8. Utilisez la liste de contrôle d'audit des API pour vous assurer que la conception de l'API répond aux exigences fonctionnelles et non fonctionnelles, notamment en matière de sécurité, de performances et de conformité.

## Questions

- Définir les entités de base, leurs attributs et leurs relations afin de créer une compréhension conceptuelle partagée entre les API.
- Utilisez le canevas d'interaction pour définir la manière dont les utilisateurs interagiront avec l'API, en veillant à ce qu'elle réponde à leurs besoins et à leurs attentes.
- Appliquer les modèles de conception REST pour créer des contrats d'interface cohérents et réutilisables qui sont validés avec les parties prenantes.
- Appliquer des modèles de conception orientés événements pour créer des contrats d'interface cohérents et réutilisables qui sont validés avec les parties prenantes.
- Appliquer les modèles de conception GraphQL pour créer des contrats d'interface cohérents et réutilisables qui sont validés avec les parties prenantes.
- Utiliser les principes de conception et le guide de style des API pour aligner vos décisions de conception sur des règles communes et permettre une validation d'audit cohérente.
- Appliquez des approches « contract-first » ou « design-first » pour définir et valider le contrat d'interface API avant sa mise en œuvre.
- Utilisez la liste de contrôle d'audit des API pour vous assurer que la conception de l'API répond aux exigences fonctionnelles et non fonctionnelles, notamment en matière de sécurité, de performances et de conformité.
- Fournir des modèles de conception réutilisables, des normes communes et des outils de validation pour les spécifications d'API. S'assurer que les décisions de conception sont cohérentes, examinées dès le début et alignées sur les objectifs métier.
- La conception d'API ne se limite pas à nommer des points de terminaison. Une bonne conception garantit que les API sont utilisables, cohérentes et alignées sur les objectifs métier et techniques. Une mauvaise conception entraîne un couplage étroit, une faible réutilisation et des retouches coûteuses entre les équipes.

## Role participation and responsibilities

- [Designer API](https://apiopscycles.com/fr/roles/api-designer.md) (lead): Conçoit le contrat d’interface, le modèle d’interaction, la cohérence et l’utilisabilité des capacités exposées.
- [Expert du domaine](https://apiopscycles.com/fr/roles/domain-specialist.md) (core): Apporte une connaissance approfondie du domaine métier, des concepts, des règles et des contraintes que la capacité ou l’interface doit refléter.
- [Propriétaire du produit API](https://apiopscycles.com/fr/roles/api-product-owner.md) (core): Pilote l’opportunité API, la priorisation et les décisions au niveau produit tout au long du cycle de vie.
- [Représentant utilisateur API](https://apiopscycles.com/fr/roles/api-consumer-specialist.md) (core): Représente les besoins des développeurs, intégrateurs ou autres utilisateurs d'API qui utilisent l'API directement.
- [Spécialiste en conformité et juridique](https://apiopscycles.com/fr/roles/compliance-specialist.md) (core): Clarifie les exigences juridiques, de confidentialité, réglementaires et contractuelles qui affectent la capacité, l’API, l’interface ou l’automatisation.
- [Spécialiste en sécurité](https://apiopscycles.com/fr/roles/security-specialist.md) (core): Assure que les risques de sécurité, les contrôles et les limites de confiance sont pris en compte tout au long du cycle de vie.
- [Architecte de la plateforme](https://apiopscycles.com/fr/roles/platform-architect.md) (consulted): Oriente les décisions relatives à la plateforme, à l’intégration, à l’évolutivité et à l’architecture qui déterminent comment la capacité ou l’API est construite et exploitée.
- [Ingénieur de livraison](https://apiopscycles.com/fr/roles/api-engineer.md) (consulted): Assume la responsabilité de la mise en œuvre, de l’automatisation, des tests et du flux de publication nécessaires pour livrer la capacité, l’API ou l’automatisation de manière fiable.
- [Responsable Documentation & DevRel](https://apiopscycles.com/fr/roles/api-devrel-specialist.md) (consulted): Responsable des contenus d'onboarding, de la communication avec les développeurs et de la qualité de la documentation API.
- [Responsable métier](https://apiopscycles.com/fr/roles/business-owner.md) (consulted): Représente les objectifs métier, le financement et les résultats attendus de l’initiative de capacité, d’API ou d’automatisation.

## Resources

- [Canevas d’interaction](https://apiopscycles.com/fr/resources/interaction-canvas.md)
- [Canevas REST](https://apiopscycles.com/fr/resources/rest-canvas.md)
- [Canevas d’événements](https://apiopscycles.com/fr/resources/event-canvas.md)
- [Principes de conception de l'API](https://apiopscycles.com/fr/resources/api-design-principles.md)
- [Canevas de domaine](https://apiopscycles.com/fr/resources/domain-canvas.md)