Comment déployer avec succès une conformité des licences pensée pour les développeurs

La conformité des licences a longtemps été perçue par les développeurs comme un frein, mais rien ne nous oblige à continuer à la considérer ainsi. Elle est essentielle pour réduire les risques pour l’entreprise. Mais pour y parvenir à grande échelle sans freiner le développement, il faut adopter une approche pensée pour les développeurs.

Au bout du compte, ce sont les développeurs qui décident des composants utilisés dans leurs logiciels. La conformité des licences logicielles n’est possible que si les développeurs disposent des moyens nécessaires pour prendre les bonnes décisions, des outils adaptés et collaborent avec les équipes conformité, qui exercent le niveau de gouvernance approprié.

L’importance de l’autonomie des développeurs

Les logiciels sont le moteur de la transformation numérique, et le monde d’aujourd’hui tourne autour de ceux qui les créent : les développeurs. Pour rester compétitifs sur nos marchés respectifs, nous attendons de ces créateurs qu’ils mettent tout en œuvre pour apporter de la valeur rapidement. Ils doivent prendre en charge leurs systèmes de bout en bout : comprendre le besoin, concevoir la solution, la mettre en œuvre, la déployer, l’exploiter et tirer des enseignements de l’expérience. Et recommencer.   

Pour que ce processus réussisse, les développeurs doivent avoir l’autonomie nécessaire pour prendre des décisions et disposer des bons outils pour les mettre en œuvre. Chaque intervention d’une équipe externe ralentit le processus et crée des frictions. Cela va fondamentalement à l’encontre de l’objectif de l’entreprise : aller vite tout en minimisant les risques.

La conformité des licences est notoirement l’un des domaines où la collaboration avec les développeurs n’a pas été fructueuse. Généralement mise en place tard dans le cycle de développement, la conformité manuelle et rigide tend à entraver les workflows de développement.

Pourtant, il est possible de faire autrement. La conformité des licences peut être repensée pour placer les développeurs au premier plan, en répondant à trois enjeux clés : donner aux développeurs les moyens d’agir et faciliter leur utilisation des outils afin qu’ils puissent adhérer à la conformité des licences, ainsi que la gouvernance pour garantir la pertinence des décisions.

Donner les moyens de prendre des décisions en matière de conformité

Les développeurs prennent d’innombrables décisions chaque jour. L’objectif doit donc être de les aider à prendre les bonnes décisions en matière de conformité.

Tester le plus tôt possible

Présenter aux développeurs une liste de problèmes de licence une fois la compilation terminée est non seulement contre-productif, mais ne fait qu’accroître les frictions entre les développeurs et les équipes de contrôle. Pour leur permettre de prendre des décisions en matière de conformité, ils doivent pouvoir détecter au plus tôt tout composant non conforme et éviter ainsi des problèmes par la suite. Cela commence dans leur environnement de développement local, puis se poursuit tout au long de leur workflow Git et, ensuite, dans le processus CI/CD.

Distinguer le noir et le blanc des zones grises

Avec plus de 200 licences open source utilisées aujourd’hui, les développeurs doivent bien comprendre les risques qu’ils pourraient introduire en choisissant un composant plutôt qu’un autre.

Toutes les licences ne sont pas des licences GPL qui imposent une ligne de conduite claire aux développeurs. Certaines sont beaucoup plus ambiguës et sujettes à interprétation. Prenons l’exemple d’un composant open source dont la licence exige une attribution. Les développeurs peuvent alors vérifier si cette attribution a bien été faite. Autre exemple : une licence inconnue. Les développeurs doivent disposer des connaissances et des outils nécessaires pour décider s’ils peuvent poursuivre le développement tout en informant l’équipe conformité, ou s’ils doivent l’interrompre dans l’attente du feu vert.

Plus les développeurs disposent de contexte, mieux ils sont armés pour évaluer les risques par rapport à la valeur du composant open source envisagé. Ce contexte peut être apporté, d’une part, par des formations destinées aux développeurs et, d’autre part, par des outils qui fournissent des informations contextuelles sur les problèmes de licence, comme les informations de copyright.

Avancer en parallèle

Les équipes de développement ne peuvent pas se permettre d’attendre la fin du projet pour solliciter les équipes de contrôle. Cette approche séquentielle n’est plus viable à l’ère du développement continu et ne fait que créer des frictions inutiles. Les développeurs et les équipes de contrôle doivent plutôt entretenir de bonnes relations et mettre en œuvre la conformité en parallèle.

De leur côté, les développeurs doivent savoir comment et quand solliciter les équipes de contrôle dès le début, en prenant contact même si cela semble compliqué ou délicat. Les équipes de contrôle doivent faciliter les échanges et les guider en communiquant des recommandations, en proposant des formations et en partageant des informations.

Favoriser l’adoption grâce à des outils faciles à utiliser

Les développeurs se voient confier de nombreuses nouvelles responsabilités, notamment en matière de sécurité et de conformité, sans être experts dans chacun de ces nouveaux domaines. Pour qu’ils adhèrent à la conformité, nous devons nous attacher à leur faciliter la prise et la mise en œuvre des bonnes décisions concernant les licences.

Intégrer les workflows de développement

Il est très peu probable qu’une équipe de développement adopte des workflows de conformité des licences chronophages et contre-productifs. L’y contraindre ne peut qu’entraîner de la méfiance et de l’hostilité.

S’intégrer naturellement et sans friction aux workflows existants basés sur Git, plutôt que de passer par une intégration externe, contribuera fortement à l’adoption par les développeurs.

Offrir une visibilité complète

Plus les développeurs ont de visibilité, plus il leur est facile d’agir sur les problèmes de licence une fois détectés. Recherchez une solution qui ne se contente pas de présenter une liste de problèmes de licence, mais qui indique clairement comment les résoudre.

Par exemple, Snyk décrit les problèmes de licence dans le contexte d’une application plutôt que d’un artefact et présente aux développeurs l’arbre complet des dépendances afin qu’ils comprennent précisément par quel chemin les problèmes ont été introduits. Ils disposent ainsi de la clarté nécessaire pour prendre rapidement des décisions éclairées.

« Conformité continue »

Dans un monde où l’adjectif « continu » précède presque tous les processus du cycle de vie moderne du développement logiciel, il va sans dire que l’automatisation est essentielle pour rendre la conformité des licences plus accessible aux développeurs. 

Automatiser la conformité des licences tout au long du SDLC permet de réduire les frictions et d’optimiser la productivité des développeurs. Intégrer des tests de licence aux builds CI/CD est un excellent point de départ, à condition que ces tests soient fiables. L’automatisation est importante, mais si les builds échouent constamment à cause de politiques mal définies, le résultat risque d’être tout le contraire.

Une gouvernance flexible plutôt que rigide

Pour donner aux équipes de développement les moyens d’agir en toute confiance, la visibilité est essentielle. Les composants intégrés à chaque itération du build doivent faire l’objet d’un suivi automatique et cohérent, avec l’appui de tableaux de bord qui présentent ces informations de manière claire et facile à consulter.

C’est vrai pour toute gestion des risques, mais particulièrement pour la conformité juridique. Les organisations doivent savoir ce qui se passe et ne peuvent pas s’appuyer uniquement sur des réunions de revue pour obtenir des informations : celles-ci doivent être intégrées aux technologies utilisées.

Une fois cela en place, il faut investir dans la distinction essentielle entre les règles strictes et les principes plus souples de la gouvernance.

Tout responsable de la conformité sait que tout n’est pas noir ou blanc et qu’il suffit parfois de démontrer qu’un effort raisonnable a été fourni. Pour les situations qui ne sont pas tranchées dans notre contexte, demandons-nous si détecter un problème peu après le déploiement et le résoudre à ce moment-là peut être considéré comme un « effort raisonnable ». C’est souvent le cas, et adopter cette approche permet de moins perturber le développement.

Faire cette distinction change tout pour l’équipe de développement. Au lieu d’empêcher un développeur de publier quelque chose ou de faire échouer le build, on peut alerter l’équipe conformité lorsqu’une licence discutable a été déployée. Elle peut alors l’évaluer rapidement et décider s’il faut agir.

Dans l’idéal, cet échange a lieu en parallèle. Plus les équipes de développement et de conformité collaborent, plus tôt elles peuvent avoir cette conversation dans le workflow de développement. Mais si elle a lieu plus tard, cela ne signifie pas qu’il faut tout arrêter. Cela ne ferait que susciter de l’hostilité.

En résumé

Dans un monde toujours plus axé sur l’autonomie des développeurs et la rapidité, la conformité des licences leur donne rarement les moyens d’agir. Pourtant, rien ne nous y oblige : nous pouvons faire de la conformité des licences une démarche pensée pour les développeurs.

Snyk aide les développeurs à adopter la conformité des licences en leur proposant une solution pensée pour eux, avec des outils faciles à utiliser, une gouvernance flexible et une visibilité de bout en bout. À la clé : un code plus conforme et, au final, des risques réduits. Pour en savoir plus, cliquez ici, ou commencez gratuitement dès maintenant.