Notre culture
Manifeste du bien-etre et de l'autonomie
Peu nous importe le nombre d'heures que vous travaillez. Ce qui compte, c'est que le systeme soit en ligne, que le code soit maintenable et que l'ingenieur qui l'a ecrit ait bien dormi.
Nous n'embauchons pas des gens pour remplir des sieges. Nous embauchons des ingenieurs pour resoudre des problemes complexes. Et les problemes complexes se resolvent mieux avec de l'autonomie, de la concentration et du repos.
Quatre principes non negociables
Ce ne sont pas des ideaux aspirationnels. Ce sont des decisions operationnelles que nous prenons chaque jour et qui definissent comment on travaille chez Digital Axios.
Resultats > Heures Deploiements reussis et processus stables.
Nous ne mesurons pas le succes en heures passees devant un ecran. Nous le mesurons en deploiements sans rollback, en pipelines d'automatisation qui traitent des milliers de documents sans intervention, et en clients qui dorment tranquilles parce que leur systeme ne tombe pas.
Un ingenieur qui corrige un bug critique en 45 minutes et va se promener a plus de valeur que celui qui passe 8 heures a simuler de la productivite.Les KPI qui comptent : disponibilite du systeme, taux d'erreurs en production, temps de resolution des incidents. Pas la pointeuse.Si votre code passe les tests, franchit la revue de code et s'integre proprement dans le pipeline CI/CD, vous avez fait votre travail. L'heure a laquelle vous l'avez fait est sans importance.
Culture asynchrone Deep Work sans interruptions.
La programmation de systemes complexes necessite une concentration profonde. Un ingenieur interrompu toutes les 20 minutes n'ecrit pas une architecture solide : il ecrit des correctifs. Nous concevons notre fonctionnement pour proteger les blocs de travail concentre.
Communication ecrite d'abord. Si quelque chose peut etre un message Slack avec du contexte, ce n'est pas une reunion de 30 minutes.Reunions avec ordre du jour prealable et duree fixe. Pas de « calls rapides » qui se transforment en une heure de divagation.Documentation comme source de verite. Les ADR (Architecture Decision Records) et les runbooks remplacent le « demande a untel, il sait ».Nous respectons les statuts « Ne pas deranger ». Quand un ingenieur est en mode Deep Work en train de resoudre un probleme de concurrence ou de concevoir un flux de microservices, cette concentration est sacree.
Respect de l'ingenieur Votre developpement professionnel n'est pas un obstacle.
Nos ingenieurs suivent des cursus a l'UTN, obtiennent des certifications AWS, contribuent a des projets open-source. Ce n'est pas quelque chose que nous « tolerons » malgre le travail : c'est quelque chose que nous encourageons parce que cela nous rend meilleurs.
Horaires flexibles concus pour que la formation academique ne soit jamais en concurrence avec le travail. Si vous avez des cours, votre emploi du temps s'adapte.Budget annuel de formation : certifications cloud, conferences techniques, cours specialises. Sans bureaucratie pour le demander.Temps de recherche protege. Ce n'est pas un avantage decoratif : c'est la raison pour laquelle nous pouvons offrir a nos clients des solutions utilisant les dernieres avancees en IA et traitement de documents.Mentorats internes entre ingenieurs seniors et juniors. Le savoir partage evolue ; le savoir accumule chez une seule personne est un point de defaillance unique.
Sante mentale Le code propre necessite des esprits reposes.
L'ingenierie heroique n'existe pas. Un ingenieur qui travaille 14 heures pour « sauver » un deploiement est le symptome d'un systeme mal concu, pas un acte de devouement. Nous concevons nos processus pour que l'heroisme ne soit pas necessaire.
Les incidents de production font l'objet de postmortems sans blame. Nous cherchons les causes systemiques, pas des coupables.Rotation d'astreinte avec des limites claires. Personne n'est « toujours disponible ». Si vous etes d'astreinte cette semaine, vous vous reposez la suivante.Charge de travail soutenable. Les sprints impossibles produisent de la dette technique qui finit par couter plus cher que l'echeance qu'ils essayaient de respecter.Un ingenieur repose detecte les conditions de concurrence, anticipe les cas limites et ecrit des tests qui couvrent les scenarios qu'un ingenieur epuise ignore.
A quoi cela ressemble en pratique
Ce ne sont pas que des mots. Voici comment nous fonctionnons concretement chaque semaine.
Sprints soutenables
Nous planifions une capacite reelle, pas des fantasmes. Nous incluons un tampon pour la recherche, la dette technique et l'imprevu. Un sprint qui necessite de l'heroisme pour etre termine est un sprint mal planifie.
Documentation plutot que reunions
Chaque decision architecturale est documentee dans un ADR. Les specifications d'API sont dans Swagger. Les runbooks sont la premiere ligne de reponse face aux incidents. Nous ne dependons de la memoire de personne.
Revues de code comme mentorat
Les revues de code ne sont pas une formalite bureaucratique. Ce sont l'occasion de partager les connaissances, de detecter les problemes avant qu'ils n'atteignent la production et d'elever le niveau technique de toute l'equipe.
Postmortems sans blame
Quand quelque chose echoue en production, nous ne cherchons pas de coupable. Nous cherchons ce qui a permis a l'erreur d'arriver jusque-la. Manquait-il un test ? Le monitoring n'a-t-il pas alerte a temps ? La documentation etait-elle ambigue ? Nous reparons le systeme, pas les personnes.
Vous voulez travailler dans une equipe qui respecte votre temps ?
Si vous etes ingenieur(e) et que vous valorisez l'autonomie, le code propre et les vrais defis techniques, parlons-en.
Contactez-nous