[Décision] Stratégie d'intégration des icônes Solaris (vendoring manuel) #1
Loading…
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
ISSUE_001 — [Décision] Stratégie d'intégration des icônes Solaris (vendoring manuel)
Problème
La charte Orange (Boosted Bootstrap) est synchronisée automatiquement dans le dépôt
via
.forgejo/workflows/ressources-sync.yml. On voudrait le même confort pour lesicônes Solaris (jeu d'icônes officiel Orange, présenté sur l'icon-finder :
https://unified-design-system.orange.com/472794e18/p/03a2da-icon-finder).
Contrairement à Boosted, les icônes Solaris ne sont pas open-source et n'ont
aucune source publique de type paquet npm ou dépôt git. Il faut donc décider
et tracer comment on les intègre, en se plaçant hors réseau Orange (hypothèse
retenue : ni VPN, ni registre npm interne Orange, ni runner CI sur le réseau
Orange).
Contexte / éléments fournis
Vérifications initiales :
@ouds/icons,solaris-icons, scopeouds… → introuvables).Orange-OpenSource(uniquement leslibrairies de composants iOS / Android / Flutter / Web).
boostedn'embarque aucune dépendance d'icônes.boosted-sprite.svgdu site de doc Boosted(
https://boosted.orange.com/docs/5.3/assets/img/boosted-sprite.svg, ~12 Ko)n'est qu'un sous-ensemble curaté pour la documentation, généré au build, absent
du dépôt git — inutilisable comme source.
be used for Orange projects. »
Élément nouveau (27/08/2026) — l'app de l'icon-finder expose deux endpoints publics :
GET /icons— le catalogue complet (catégories, sous-catégories, mots-clés).GET /assets/svg/{slug}.svg— une icône, déjà au format du sprite officiel(mêmes chemins,
fill="currentColor").https://solaris-icon-finder-production-701563482613.europe-west1.run.app/(URL susceptible de changer quand Orange redéploie).
Ces deux endpoints suffisent à reconstruire le sprite officiel sans le réseau
Orange ni authentification. Un script Python le fait :
.ressources/orange-solaris-icons/telecharger-icones-solaris.py(télécharge les1610 icônes en parallèle, remplace
<svg>par<symbol>, normalise lescouleurs figées en
currentColor, et compare au sprite précédent — identifiantsapparus / disparus).
Contrainte : hors réseau Orange — seuls les endpoints publics de l'icon-finder
sont exploitables.
Proposition / solution / réponse / action — DÉCIDÉE
Renoncer à un sync automatique de type Boosted (pas de source npm/git). Adopter un
vendoring délibéré du jeu complet, régénérable par script :
.ressources/orange-solaris-icons/contenant :solaris-icons-sprite.svg: sprite SVG, jeu complet (1610 symboles, ~2,1 Mo).C'est le fichier utilisé par le code applicatif.
icones.json: catalogue complet (slug, titre, catégorie, sous-catégorie,style, mots-clés FR + EN) — source de vérité pour retrouver le nom d'une icône.
svg/: les 1610 SVG individuels rangés par sous-catégorie (33 dossiers).telecharger-icones-solaris.py: script de (re)génération.README.md: licence, date d'export, méthode, identifiant d'un symbole,usage
<use href=…#id>, procédure de mise à jour..gitattributes:.ressources/orange-solaris-icons/** -text(verbatim, pasde conversion CRLF).
.gitignore: aucune règle n'exclut ce dossier — rappel explicite ajouté encommentaire.
.forgejo/workflows/README.md: section expliquant pourquoi les icôneséchappent au sync automatique alors que Boosted en bénéficie (source non
publique), et que le sprite est régénéré manuellement par le script.
<svg aria-hidden="true"><use href="/…/solaris-icons-sprite.svg#navigation-arrow-left"/></svg>.Identifiant d'un symbole :
<sous-catégorie>-<slug>en minuscules, espaces →traits d'union ;
slugseul si la sous-catégorie est vide.--dossier .ressources/orange-solaris-icons), qui réutilise les SVG déjà présents etliste les identifiants apparus / disparus. Actualiser la date d'export du
README.md. Si le script ne répond plus : relever la nouvelle URL de l'iframedans l'onglet Réseau du finder, la passer en
--base.Écart avec la version initiale de l'issue
La première rédaction retenait un sous-ensemble limité aux icônes réellement
utilisées, généré à la main depuis l'UI de l'icon-finder, sans script. Décision
révisée le 27/08/2026 : le script rend l'export complet trivial et
reproductible, ce qui évite de régénérer le sprite à chaque nouvelle icône
nécessaire. Le coût (~2,1 Mo servis via
<use>) est jugé acceptable.Le choix du mécanisme de rendu (sprite vs SVG individuels) reste à confirmer dans
_projet/ux-ui.mdvia l'agent.forgejo/agents/2-interface-utilisateur.mdquandce document sera ouvert. Le jeu complet étant vendoré, aucune liste d'icônes n'est
à arbitrer.
Options identifiées
Recommandation
Option « jeu complet vendoré, régénérable par script ». Seule compatible avec la
contrainte hors réseau Orange, coût faible, et le script supprime le travail
manuel répétitif de la version initiale.
Conséquences de la décision
jeu Solaris n'est répercutée que sur exécution manuelle du script.
elle peut changer sans préavis (procédure de récupération documentée).
le catalogue.
solaris-icons-sync.ymlcalqué surressources-sync.ymldevientenvisageable (le script n'utilise que des endpoints publics) — non fait,
candidat séparé.
Critères d'acceptation
.ressources/orange-solaris-icons/créé avecsolaris-icons-sprite.svgetREADME.md.README.mddu dossier : date d'export, méthode, mention de licence, procédure de mise à jour..gitattributescouvre.ressources/orange-solaris-icons/**en-text.git ls-treede la branche) — après commit..forgejo/workflows/README.mdexplique pourquoi les icônes ne sont pas synchronisées._projet/ux-ui.mdlors de son ouverture.Priorité proposée
Basse — aucun blocage tant qu'aucune interface n'est en cours de
construction. L'intégration technique est faite ; reste le commit et le report
dans
_projet/ux-ui.md.Périmètre estimé
Questions ouvertes
solaris-icons-sync.ymlmaintenant, ou attendre quele besoin d'icônes soit réel ?
<use>vs SVG inline vs composant) sera tranchédans
_projet/ux-ui.md— laissé ouvert ici.Labels proposés
type:decisionpriority:lowarea:infraarea:docsarea:ui[Décision] Stratégie d'intégration des icônes Solaris (vendoring manuel)to [Décision] Stratégie d'intégration des icônes Solaris (vendoring manuel)Resolue. Integration technique poussee sur main dans le commit
88d9170.Decision revisee vs version initiale : jeu complet regenerable par script au lieu d'un sous-ensemble genere a la main.
Suivi restant, hors de cette issue : reporter le choix du mecanisme de rendu dans _projet/ux-ui.md via l'agent 2-interface-utilisateur.md quand ce document sera ouvert ; workflow solaris-icons-sync.yml optionnel a evaluer.