Politique de cycle de vie du développement logiciel

Dernière mise à jour : 25 mars 2026

Responsable : projet open source Rockxy

Résumé

Ce document décrit l'approche du projet Rockxy en matière de développement logiciel. En tant qu'outil de développement macOS open source, nous nous imposons des standards élevés de qualité, de sécurité et de transparence. Chaque ligne de code est publiquement vérifiable, et notre processus de développement reflète cette ouverture.

Champ d'application

Cette politique s'applique à tout le travail de développement au sein du projet Rockxy, y compris l'application principale, les outils auxiliaires, l'infrastructure de build et ce site web. Elle couvre l'ensemble du cycle de vie, du concept initial à la maintenance continue.

Principes fondamentaux

  • Qualité — Nous livrons des logiciels fiables, performants et bien testés. Chaque version passe par une assurance qualité automatisée et manuelle avant d'atteindre les utilisateurs.
  • Sécurité — La sécurité est intégrée à chaque étape. Rockxy gère du trafic réseau sensible, et nous prenons cette responsabilité au sérieux : aucune télémétrie, aucune collecte de données, et des audits réguliers des dépendances.
  • Transparence — Le code source est public. Le suivi des problèmes est public. Les décisions concernant l'architecture, les priorités et les compromis sont documentées de manière ouverte.
  • Communauté — Les contributions de la communauté font avancer Rockxy. Nous maintenons des directives de contribution claires, des revues de code réactives et un environnement de développement inclusif.

Étapes du SDLC

1. Idéation et cadrage

Les nouvelles fonctionnalités et améliorations sont proposées via les Issues GitHub et les discussions communautaires. Nous évaluons les propositions en fonction de l'impact utilisateur, de la faisabilité technique et de l'alignement avec la feuille de route du projet avant d'engager des ressources.

2. Planification et architecture

Les propositions acceptées passent à une phase de conception où nous définissons l'architecture système, identifions les dépendances, évaluons les risques et établissons les critères d'acceptation. Pour les changements significatifs, nous rédigeons des enregistrements de décisions architecturales (ADR) dans le dépôt.

3. Développement

Tout le code est développé sur des branches de fonctionnalités et soumis via des pull requests. Chaque PR nécessite une revue de code avant la fusion. Nous suivons les conventions Swift et SwiftUI, utilisons des messages de commit explicites et gardons les changements ciblés et faciles à examiner.

4. Assurance qualité et tests

Nous maintenons des tests unitaires, des tests d'intégration et des listes de vérification QA manuelles. Le code sensible à la sécurité (interception TLS, gestion des certificats, configuration du proxy) fait l'objet d'un examen approfondi supplémentaire. Nous testons sur les versions macOS prises en charge avant chaque version.

5. Déploiement et publication

Les versions suivent le versionnement sémantique. Chaque version inclut une entrée de changelog, un build signé et une distribution via les canaux officiels du projet. Nous utilisons des pipelines de build automatisés pour garantir des builds reproductibles.

6. Maintenance et évolution

Après la publication, nous surveillons les retours de la communauté, trions les rapports de bugs et livrons des correctifs selon les besoins. Les dépendances sont mises à jour régulièrement, et nous suivons les avis de sécurité en amont pour tous les paquets tiers.

Équipe et dynamique communautaire

  • Mainteneurs principaux — Responsables des décisions architecturales, de la gestion des versions et de la direction à long terme du projet.
  • Contributeurs — Membres de la communauté qui soumettent du code, de la documentation, des traductions et des rapports de bugs. Toutes les contributions passent par le processus standard de revue de PR.
  • Utilisateurs — Fournissent des retours, signalent des problèmes et valident les fonctionnalités. Les retours des utilisateurs façonnent directement la feuille de route.

Documentation et partage de connaissances

Nous maintenons de la documentation à plusieurs niveaux :

  • Commentaires dans le code pour les détails d'implémentation non évidents
  • Enregistrements de décisions architecturales pour les choix de conception significatifs
  • Documentation destinée aux utilisateurs et guides d'installation
  • Directives de contribution et normes de codage dans le dépôt
  • Articles de blog d'ingénierie couvrant des analyses techniques approfondies

Conformité et gestion des risques

Nous suivons les meilleures pratiques de l'industrie pour le développement logiciel sécurisé. Les audits réguliers des dépendances, la signature du code et les builds en bac à sable réduisent les risques liés à la chaîne d'approvisionnement. Rockxy ne collecte aucune donnée utilisateur, ce qui simplifie la conformité réglementaire. Les vulnérabilités de sécurité peuvent être signalées via notre politique de sécurité.

Amélioration continue

  • Rétrospectives post-publication pour identifier les améliorations de processus
  • Revue régulière des outils, dépendances et infrastructure de build
  • Retours de la communauté intégrés au processus de développement
  • Partage de connaissances à travers des articles de blog et des discussions ouvertes

Modifications de cette politique

Les mises à jour de cette politique sont versionnées dans le dépôt source Rockxy sur GitHub. La date « Dernière mise à jour » en haut reflète la révision la plus récente. Les modifications importantes seront notées dans le changelog du projet.

Contact

Si vous avez des questions sur cette politique ou notre processus de développement, ouvrez une issue sur GitHub.