Romain Lecault

Si les grandes structures (les fameux « grands comptes ») ont bien un avantage sur les petites startups, c’est l’absence de peur quant à leur avenir à court terme. Les fonds propres étant suffisants, tenter quelque chose et échouer passe simplement en « pertes et profits » et on passe à autre chose. Ce n’est pas le cas pour les petites boîtes. Ces dernières n’ont pas le luxe de rater puis recommencer ; bien souvent, un mauvais choix met en jeu la survie même de l’entreprise.

Habituellement, les tâches Ansible sont séquentielles et indépendantes entre elles. Cependant, il arrive parfois qu’on ait besoin de les regrouper, pour gérer les erreurs en une fois ou conditionner plusieurs tâches. C’est ce dernier cas qui va nous occuper aujourd’hui, car il y a une subtilité à connaître pour ne pas se laisser surprendre. Et le moins qu’on puisse dire, c’est qu’elle est drôlement piégeuse. Chez Ansible, toute tâche peut être conditionnée :

Il y a quelques années, alors que je présentais une pile conteneurisée sur laquelle je travaillais à un confrère, celui-ci m’a affirmé avec aplomb : « tu ne passeras jamais de Docker Compose à Kubernetes ». Bien sûr, ce qui est affirmé sans preuve peut être nié sans preuve1, mais cette phrase est révélatrice d’une réflexion insidieuse dans le monde informatique. Aussi, étudions-la de plus près pour révéler ce qui s’y cache.

De nombreuses questions traversent la conception d’une API : quel protocole ? avec quelle sécurité ? quelles sont les actions possibles, avec quelles informations et sur quelles ressources ? Chaque réponse doit être intégrée au code et dûment documentée pour aider le consommateur à savoir comment interagir avec l’applicatif. Ça ne paraît rien comme ça, mais cette documentation est un enjeu central : si l’on dit qu’une API est aussi bonne que sa documentation, c’est qu’elle est la condition du succès de l’API elle-même.