Tech Archives - Ekino FR

KEYNOTE – Fantastic functions and where to find them 

La première keynote de cette semaine (une par jour tout de même !) était présentée par Freek Van der Herten, co-owner de Spatie et Laravel enthousiaste. 

Très bonne idée d’avoir invité un speaker ne faisant pas partie de la communauté Drupal ! D’autant plus que son blog https://freek.dev/ recèle d’articles intéressants sur PHP !  

Après un bref rappel des avancées de PHP ces dernières années, il a appelé la communauté Drupal à garder un esprit ouvert, et s’inspirer d’autres communautés, d’autres langages. Quoi de mieux que de nous démontrer ce qui se fait ailleurs (notamment par lui) dans la communauté Laravel. 

Pour ça, il nous a fait la démo de quelques outils (Invade, Fork, Ray, Livewire). Un bon rappel pour les connaisseurs et une présentation intéressante pour les découvrir ! 

I just became team-lead… Now what? 

Sujet très intéressant de Frederik Vabrabrant, “Keyboard for hire” (une dénomination amusante pour dire freelance, c’est lui-même qui le dit !) ! 

Fredrik Vabrabrant Drupal Dev Days
Fredrik Vabrabrant – Drupal Dev Days

Ce talk fait réfléchir sur la place de chacun dans une équipe. Plus encore, il nous invite à découvrir la vie d’un team-lead au travers d’un projet “fictif” qui “ne s’est bien évidemment jamais déroulé comme raconté” ! Oui, rien que ça !

Sans trop spoiler, il y a 3 points cruciaux à garder en tête au sein d’une équipe : Confiance, Honnêteté et Contexte. 

C’est un talk que nous recommandons vivement d’écouter si jamais vous avez la possibilité de le voir dans une autre conférence ou sur Internet ! L’un des temps forts de cette semaine pour nous ! 

Do you know what your Drupal is doing? Observe it! 

Luca Lusso (mainteneur du module Devel notamment) a présenté une solution possible pour observer une application Drupal. Elle est basée sur Opentelemetry qui va se charger de collecter des traces, des logs (structurés via Monolog) et des métriques (fournies par Prometheus) afin de les stocker et de les visualiser dans Grafana

Sleep – Work – Live (8-8-8) 

Sonja Baddy, co-owner de 1xInternet et siégeant au bureau de l’association Drupal, nous a présenté son point de vue sur l’optimisation du temps dans une journée de travail. 

Avant d’entamer sa présentation, elle a recueilli des petites vidéos de la communauté Drupal Ukrainienne. Une vidéo qui a réussi à émouvoir de nombreuses personnes dans la salle. 

Sa présentation se base sur 4 principes : Travail en équipe, communication, collaboration, travail en agence/à distance.  
Pour avoir un bon travail en équipe, elle a parlé de principes très simples : éviter de laisser une personne seule (autant pour la connaissance du projet que pour le ressenti que la personne peut avoir), garder une expertise sur une stack, éviter des projets avec des stacks trop différentes. 

En ce qui concerne la communication et la collaboration, Sonja a donné les tips qui ont été mis en place chez 1xInternet (en partant du livre blanc sur le remote de Gitlab). Tout est basé sur la simplification des processus, par exemple, limiter les mails en interne pour laisser les gens se concentrer sur leur travail ou réduire les réunions à l’essentiel. 

Sonja Baddy Drupal Dev Days
Sonja Baddy – Drupal Dev Days

La présentation de Sonja est remplie de conseils très intéressants pour simplifier les processus et les communications ! 

Drupal.org GitLab Acceleration Update 

Pour ceux qui n’ont pas suivi, cela fait maintenant quelques années que Drupal a entamé un plan de migration afin d’utiliser Gitlab. Neil Drumm, Architecte de Drupal.org pour la Drupal Association, a effectué un point d’avancement sur la migration et sur ce à quoi il faut s’attendre à l’avenir. Depuis 2020 il est possible de passer par des merge request pour les projets qui le souhaitent au lieu des traditionnels fichiers .patch. Bientôt tout cela sera de l’histoire ancienne et nous allons pouvoir dire au revoir à ces fameux fichiers .patch.  

L’idée derrière cette migration (outre que ça nous fait plaisir d’utiliser Gitlab) est de simplifier drupal.org et permettre sa mise à jour vers des versions du Core Drupal plus récente que la 7 ! 

Si vous souhaitez suivre cela, n’hésitez pas à regarder l’issue concernée

Conclusion 

Mis à part quelques soucis techniques dans l’une des deux salles de conférence, cette édition des Drupal Dev Days a été un franc succès ! 

Nous avons apprécié les repas végétariens du midi, les évènements proposés le soir comme la visite du Château des Comtes ! 

Gent 2 Drupal Dev Days
Château des Comtes – Drupal Dev Days

Ou la soirée Board Gaming prévue par Platform.sh ! 

Équipe Drupal Dev Days
Équipe – Drupal Dev Days

Un grand merci aux organisateurs qui ont tenu bon pendant ces deux années d’incertitude, aux sponsors qui n’ont jamais cessé de soutenir l’évènement et aux speakers de qualité ! 

Équipe #2 Drupal Dev Days

En espérant retrouver la communauté à Prague lors de la DrupalCon Europe 2022 avec des speakers ekino de nouveau ! 

Équipe #3 Drupal Dev Days

DevSecOps : les garanties sécurité dans l’industrialisation logicielle

La sécurité applicative se garantit dans la durée Trop régulièrement, malheureusement, des incidents de sécurité paraissent dans l’actualité. Tout le monde est concerné, quelle que soit la technologie, de la simple librairie (de logs par exemple…) à l’application métier complexe qui voit ses millions de données utilisateurs s’envoler dans la nature. Parfois, cela peut avoir […]

Lire la suite de DevSecOps : les garanties sécurité dans l’industrialisation logicielle

Au début, tout va toujours bien !

Vous sortez de la dernière réunion validant les ultimes maquettes graphiques du projet. Chacun est très excité à l’idée du lancement, car enfin, tout vous paraît clair et concret, le design tangible sous les yeux. Vous n’attendez qu’une chose : que l’équipe de développement entame l’implémentation des premières fonctionnalités.

Le calendrier est bien défini pour les semaines à venir et les choses démarrent. Une fonctionnalité, puis une autre, et encore une autre… Vous êtes mis à contribution pour la recette. Mis à part quelques retours de temps à autre, tout se déroule plutôt bien.

Les premiers symptômes.

Puis arrive un jour où vous remarquez que le formulaire de contact ne fonctionne plus. Vous l’aviez pourtant testé il y a un mois. Il marchait ! De plus, aucune modification du code ne semble avoir pu impacter cette fonctionnalité… C’est curieux ! Ce problème, qui fait partie de la vie courante d’une application, est la raison première des tests : éviter les régressions.
 On a fini par comprendre la raison : un nouveau développeur, intégré récemment au projet, a mis à jour des librairies. Le changement semblait anodin et on lui avait justement confié cette tâche pour qu’il rentre en douceur sur l’application.
 Que va-t-il advenir si l’équipe continue à développer sans tests ? Ce type de situation se reproduira continuellement. La part de temps alloué à revenir sur des choses qui fonctionnaient, se fera de plus en plus grande. Et le temps, c’est de l’argent ! Mais ce n’est que le début des ennuis.

La frustration s’installe…

Vous vous rendez compte qu’il vous faut être de plus en plus attentif à la stabilité globale de l’application. Et donc, consciencieusement, vous vous appliquez à effectuer des vérifications complètes sur les parties les plus critiques. Vous perdez de plus en plus de temps à faire de la recette, à remonter des anomalies, à faire comprendre le cheminement suivi pour reproduire un bug. Du côté de l’équipe technique, ce n’est pas vraiment la joie non plus ! Pour finir le projet dans les temps, il va falloir mettre les bouchées doubles. Mais le client crée des tickets de bugs qui, dans un cercle vicieux, prennent le pas sur le reste à faire.

Des deux côtés, chacun expérimente dans la douleur d’avoir négligé les tests. Pour continuer à avancer, il va falloir corriger le tir.

Rétablir la confiance.

La dette technique est importante, mais les deux parties sont motivées à redresser la situation progressivement. D’un commun accord, les développeurs mettent en place des tests automatisés sur les parties les plus critiques. Cela vous libère du temps : dans votre check-list, plus besoin de vérifier une énième fois ce fameux formulaire de contact. Enfin !

Il y a également un fait nouveau : l’un des ingénieurs vous demande comment l’application doit se comporter, sur un cas un peu en marge, qu’il a décelé en écrivant un test. Cela pourrait être par exemple : que faire si telle valeur n’existe pas dans votre base client ? Doit-on stopper la procédure, ou proposer une alternative ?

De fait, c’est une situation à laquelle vous n’aviez pas songé : un premier exemple de raffinement des comportements ; un gain pour l’expérience finale utilisateur.

Un cercle vertueux.

Le projet ne sortira pas à temps, la faute à la négligence première. Mais désormais, l’application est plus solide. Et surtout, les bons réflexes sont intégrés à la routine comme une bonne hygiène de vie. Avec eux, viennent des bénéfices pas forcément attendus.
Bientôt, le projet sera mis en ligne. Demain d’autres développeurs assureront la maintenance et un nouveau « Product Owner » reprendra le flambeau. Ils hériteront tous d’une plus-value… voyons pourquoi.
 Le nouveau PO ne maîtrise pas pleinement le métier, et manque de chance, son prédécesseur est parti trop précipitamment pour assurer une transition solide. Une partie de la connaissance a disparu avec lui… 

En l’absence de tests, c’est le comportement de l’application qui fait foi. Mais comment être pleinement sûr qu’il ne s’agit pas plutôt d’un bug ? On pourrait croire ce genre de situations à la marge, mais je la mentionne pour l’avoir déjà rencontrée. Si, par contre, des tests sont présents et explicites, pour confirmer les comportements voulus, alors l’équipe de développement est capable, avec confiance, de remonter de l’information.

Les tests ont valeur de vérité. Ils servent alors de documentation, de base de compréhension.

Intégrer au quotidien de la qualité, a un bénéfice humain pas nécessairement quantifiable. Il s’agit plutôt d’un ressenti sur le confort de travail, à tous les niveaux.

S’appuyer sur une base solide permet de se concentrer sur ce qui a de la valeur ajoutée : les fonctionnalités au service de l’utilisateur final.
 Mais aussi, c’est prendre le pli d’un processus de communication sain, où l’on anticipe au mieux les cas d’usage, où les ambiguïtés sont levées en amont, où l’on s’entend sur un vocabulaire commun. L’équipe technique s’enrichit de la connaissance métier, et en retour le client comprend mieux le fonctionnement de son application.

En résumé…

Faites de l’intégration des tests une routine de travail qui engage l’ensemble des métiers. Au-delà des aspects purement techniques, on peut également souligner de nombreux effets vertueux qui en découlent. Pour n’en citer que quelques-uns :

– Assurance aux non-régressions

– Gain de temps à la recette

– Confort de travail

– Communication renforcée

– Anticipation des cas d’usage

– Documentation historique au projet, source de vérité

Cette liste, bien que non exhaustive, est loin d’être négligeable et devrait suffire à convaincre vos clients de tout l’intérêt des tests.

Comment utiliser la combinaison pour créer une condition if-else dans RxJS

Introduction Moi, c’est Omar, ingénieur front chez Ekino. Souvent lorsque je démarre un projet RxJS existant, je constate que les développeurs respectent le principe de la programmation réactive via l’utilisation d’observables et d’opérateurs RxJS sauf dans le cas d’un if-else qu’ils utilisent toujours de façon impérative. J’ai demandé à beaucoup de ces développeurs la raison […]

Lire la suite de Comment utiliser la combinaison pour créer une condition if-else dans RxJS

Quels sont les critères influant sur le choix d’un ERP ?

Comme pour tout projet – le point de départ est de formaliser le besoin. Dans le cadre de la mise en œuvre ou de la refonte d’un système ERP, cette formalisation revêt une importance toute particulière étant donné la position centrale que joue ce type d’outil dans la vie d’une entreprise.

À la croisée des chemins de tous les processus opérationnels de l’entreprise, l’ERP répond à une grande variété de challenges métier qu’il est nécessaire de prendre en compte lors du cadrage du chantier.

La solution doit avant toute chose répondre aux besoins de vos utilisateurs. Ils sont au cœur de l’entreprise et sont directement impliqués dans les processus opérationnels. Les impliquer dans cette démarche, c’est s’assurer que la définition du besoin ne soit pas biaisée et que votre futur ERP soit adapté à la réalité du terrain. Ils sont ceux qui vous permettront de cartographier de manière exhaustive le besoin fonctionnel, sa complexité et sa criticité pour les opérations quotidiennes.

D’autres typologies de besoins entrent également en ligne de compte :

  • Les enjeux de votre secteur d’activité : chaque secteur d’activité dispose de ses propres normes et/ou spécificités. C’est la raison pour laquelle il existe des progiciels ERP spécialisés. Ainsi, l’industrie dans laquelle votre entreprise évolue impacte nécessairement la définition de votre besoin et votre choix.
  • Votre stratégie : ou plus exactement, penser au futur et vous assurer que votre besoin prend en compte la trajectoire stratégique de votre organisation. Par exemple, une entreprise en croissance ouvrant de nouvelles business units fréquemment, voudra un outil capable de gérer les processus opérationnels de l’ensemble de ses entités présentes et futures.

Le cahier des charges va conditionner une grande partie du choix en fonction de la complexité du besoin et de son évolution. Cependant, d’autres paramètres peuvent entrer en ligne de compte, et le meilleur choix n’est pas forcément celui que l’on soupçonne.

Quels sont les différents types d’ERP ?

On peut regrouper les ERP en 2 grandes familles. Les logiciels ERP généralistes et spécialisés.

  • L’ERP horizontal (généraliste) : il offre des fonctions adaptées pour des processus courants sur l’ensemble des opérations de l’entreprise. Cependant, il est important de garder à l’esprit qu’hormis dans le cadre d’activités très spécifiques (comptabilité, RH, ventes…), il est peu probable de trouver une solution qui correspond exactement à vos besoins. Si les possibilités de développement personnalisé sont limitées, le choix d’un logiciel ERP généraliste est peu risqué et sa gestion reste simple.
  • L’ERP vertical (spécialisé) : il s’agit de solutions conçues par métier. La couverture fonctionnelle est donc par définition moindre que celle de l’ERP horizontal. Mais leur modularité permet d’adapter la solution aux différents besoins grâce à des surcouches. L’intérêt de l’ERP vertical est que ces solutions répondent aux besoins de domaines d’activité spécifiques (ex : planificateur de production pour l’industrie).

Dans l’hypothèse où une solution ERP existante (horizontale ou verticale) répondrait aux besoins identifiés dans votre cahier des charges, il est très probable que votre choix se porte sur un progiciel : pas la peine de réinventer la roue.

Cependant, il est possible de ne pas trouver chaussure à son pied. La question du développement sur mesure se posera cependant si vous souhaitez vous munir d’une solution adaptée à 100% à votre entreprise et vos process. Comme nous avons pu le faire pour l’institut Ipéria.

Bien qu’à première vue la construction sur mesure d’un logiciel spécifique peut systématiquement sembler être la solution la plus adaptée, ce choix aura des impacts qu’il est nécessaire de prendre en compte au préalable. Notamment en ce qui concerne la maintenabilité et les coûts liés à votre système.

La maintenabilité de votre ERP

Même les logiciels spécifiques les mieux conçus et reposants sur des fondations solides ne résistent pas toujours à l’épreuve de multiples aménagements successifs. Il est donc nécessaire d’anticiper les défis de maintenance lorsque des développements spécifiques sont impliqués et que votre écosystème se complexifie.

Cependant, une solution sur mesure offre plus de contrôle et limite la dépendance vis-à-vis des montées de version et des évolutions réalisées par l’éditeur.

Dans le cas où des développements spécifiques sont réalisés autour d’une solution progicielle, l’ERP n’est pas toujours capable d’assurer la compatibilité ascendante de ses évolutions développées sur mesure. Cela signifie que l’application doit être testée dans son ensemble à chaque mise à jour de la solution. Il est même parfois nécessaire d’opérer d’importantes migrations.

Les coûts relatifs à la mise en œuvre ou la refonte d’un ERP

De tels projets peuvent impacter l’ensemble des services opérationnels de votre organisation. Il s’agit donc de projets d’ampleur par définition. Et le périmètre et les coûts qui y sont associés sont relatifs à la taille de la structure.

Le nombre d’utilisateurs est ainsi un facteur non négligeable qui rentre en compte dans le budget global pour le coût des licences si le choix se porte vers un ERP progiciel.

Les coûts relatifs aux développements spécifiques quant à eux sont des coûts “habituels” relatifs à un projet digital. Ils sont donc à prendre en compte dans le développement d’une solution ERP sur mesure, ou dans le cas de développement de modules spécifiques autour d’une solution progicielle.

D’autres coûts viennent ensuite tels que les coûts relatifs à la maintenance. Ces derniers sont en partie couverts par les licences lorsqu’il s’agit de progiciels, et doivent être définis lorsque des développements sur mesure sont impliqués.

Enfin, il est nécessaire de provisionner un budget couvrant les évolutions métier, technologiques et possiblement règlementaires (RGPD, accessibilité, etc…) pouvant impacter la solution. 

Ainsi, il ne s’agit pas uniquement de prévoir les coûts de mise en œuvre, mais bien de réaliser une projection financière sur 3 à 5 ans afin de pouvoir pallier les défis futurs.

Le tout sans oublier les coûts relatifs à la formation et l’acculturation.

Adoption et conduite du changement

Compte tenu du rôle que joue un logiciel ERP au sein d’une organisation, ces projets sont très souvent stratégiques pour l’entreprise. La question de l’adoption par les utilisateurs est donc cruciale.

La stratégie de conduite du changement mise en œuvre doit donc être à l’échelle de l’impact qu’un tel projet peut avoir sur les utilisateurs.

Les impliquer en amont du projet et dans le cadrage fonctionnel de la future solution participera bien évidemment à son adoption. Mais cela ne suffit pas. Il est nécessaire de continuer à les préparer au changement tout au long du projet, et d’anticiper la formation au nouvel outil.

La résistance au changement sera fonction d’un grand nombre de paramètres. Mais dans le cas de solutions logicielles, il est bien plus simple pour des utilisateurs d’adopter un logiciel entièrement adapté à leur besoin. La réponse fonctionnelle qu’offre votre futur ERP à vos équipes est donc clé afin d’assurer le changement.

En conclusion

Chaque solution dispose de ses avantages et de ses inconvénients. 

D’un côté, le choix du progiciel, qui apportera un time to market avantageux et une réassurance due à la présence de l’éditeur au prix d’une certaine dépendance vis-à-vis de ces derniers.

De l’autre, le développement sur mesure qui répondra plus spécifiquement aux besoins de votre entreprise et vous apportera plus de flexibilité et de liberté quant à son évolution au prix d’un investissement souvent supérieur.

La solution hybride, permettant de gérer les principales règles métier grâce à un progiciel tout en développant des modules sur mesure afin de s’adapter à votre entreprise peut sembler être la solution idéale. Force est de constater qu’entre ERP progiciel et ERP 100% sur mesure, une pléthore de solutions peut exister.

Chaque projet dispose donc d’une réponse qui lui est propre. C’est pourquoi il est crucial d’établir des critères qui conditionnent le choix, et de s’informer sur les avantages et inconvénients de chaque solution afin de répondre à un besoin dans un contexte qui nous est propre.

Et bien qu’il existe de nombreux critères afin de déterminer la solution qui correspond aux besoins de votre entreprise, le critère fondamental reste le besoin de vos utilisateurs métier !

Sébastien Collery nous parle de son métier de Directeur de l’agence ekino Bordeaux

Tu as dû le comprendre, chez ekino, chaque collaborateur compte : Ingénieur, Consultant technique, Designer… Après avoir rencontré Caroline, Nicolas, Antoine et Michael, rendez-vous cette fois-ci avec le big boss de l’agence bordelaise, Sébastien Collery. Arrivé en 2009 en tant que stagiaire, Sébastien a.k.a Sabiche pour les intimes a un parcours marqué par une évolution […]

Lire la suite de Sébastien Collery nous parle de son métier de Directeur de l’agence ekino Bordeaux
  • « Je n’avais pas nécessairement la formation ni trop d’expérience dans le domaine »

Le premier rayon de soleil est apparu dès le début de notre conversation avec Antoine. C’est avec énergie qu’il nous raconte ses premiers pas à ekino : 

Antoine : Mon 1er contact, c’était avec un des architectes de l’époque du Pôle Java avec un haut niveau d’expertise, et ça été chouette ! J’ai candidaté sans vraiment y croire parce que je n’avais pas nécessairement la formation ni trop d’expérience dans le domaine. Ce côté “confiance accordée”, j’ai trouvé ça super cool et je n’avais qu’une hâte, c’était de débuter chez ekino ! 

Antoine intègre ainsi les équipes bordelaises en tant qu’ingénieur Java. Sa montée en compétence rapide le positionne aujourd’hui comme ingénieur back-end. Mais, au fait, c’est quoi un ingénieur back-end ?

Si tu devais expliquer ton poste à ta grand-mère, qu’est ce que tu lui dirais ? 

Antoine : Pour ma grand-mère, je pense que je serai obligé de passer par une analogie parce que sinon elle ne comprendrait rien ! J’essaierai de lui dire que mon job est d’essayer de faire d’un ordinateur ou d’un outil informatique un bon assistant pour un professionnel, quel qu’il soit.

Alors oui l’informatique a le potentiel d’être un assistant pour faire plein de choses, mais il faut très précisément lui expliquer, étape par étape, tout ce qu’il va être amené à réaliser. 

Antoine : Mon travail au quotidien, c’est d’abord de rédiger cette procédure, cette recette, étape par étape. Il s’agit également de comprendre ce que l’utilisateur final attend de son assistance. L’assistant que je vais former va devoir interagir avec d’autres assistants pour arriver au service attendu, et qui sont gérés par d’autres équipes.”

Normalement à ce stade, sa grand-mère a tout compris, et vous aussi on espère ! Et comme toute grand-mère, elle souhaite savoir si son petit-fils Antoine se plait dans son travail.  Il nous explique alors que ce qu’il aime réside dans les valeurs du partage.

  • « Ce qu’on attend vraiment, c’est une grosse part d’envie »

Antoine: On a des moments d’échanges techniques : que ce soit au sein de notre pôle ou avec les autres équipes. Ça peut être l’occasion, soit de présenter, soit de recevoir les expériences des autres.

Bon, peut-être qu’à ce stade, cette interview, aussi honnête soit-elle, est un peu trop corporate me direz-vous (pas de tabou entre nous !), alors allons droit au but.

Qu’est-ce que vous attendez d’un ingénieur Java ? 

Antoine: Ce qu’on attend vraiment, c’est une grosse part d’envie. Que ce soit une envie d’apprendre, de faire apprendre à ceux qui nous entourent, une envie de s’impliquer et de faire avancer les choses, vraiment d’être moteur. 

C’est par l’empathie et le soutien qu’Antoine insiste sur la capacité à s’épauler. 

Antoine: Ça implique aussi d’être capable de se remettre en question, de vouloir s’améliorer en permanence, tant dans la technique, que dans l’interaction les uns avec les autres et comment on construit cette équipe Java.

Si tu devais résumer ekino en 1 mot ? 

Antoine: Honnêtement je voudrais tricher et dire “ekino”. Parce que c’est une espèce de mélange de plein de choses et à force d’y vivre et d’y être, je trouve que ce qui résume le mieux tout ça, c’est ekino ! 

Si tu te retrouves dans ces valeurs de transmission et de partage, chères aux équipes d’ekino, envoie-nous ta candidature. Lunettes sur le nez,  Antoine et son équipe ont hâte de te rencontrer! 

Caroline nous parle de son métier de Manager Adjoint chez ekino

Salut Caroline. On va entrer dans le vif du sujet en parlant de ta grand-mère : si tu devais lui expliquer ton poste, qu’est ce que tu lui dirais ? 👵🏻 Caroline : Alors mamie, mon travail, c’est consultante technique. Il s’agit de vulgariser le savoir-faire pour être en capacité de dialoguer avec toutes les […]

Lire la suite de Caroline nous parle de son métier de Manager Adjoint chez ekino

Tu peux nous expliquer ce que fait un consultant technique ? 

Michael : J’essaie de faciliter le travail de l’équipe. L’objectif est de recueillir un besoin, de pouvoir échanger avec le client, de comprendre techniquement les choses et de pouvoir les transmettre à l’équipe. 

  • « C’était le côté un peu web agency, avec beaucoup d’autonomie, d’apprentissage qui m’a plu. »

Avant cela, Michael nous a confié qu’il travaillait dans une petite agence web-marketing. Sa volonté de trouver plus de moyens techniques et humains pour une meilleure mise en place des projets l’a donc attiré chez ekino.

Michael : C’était le côté un peu web agency, avec beaucoup d’autonomie, d’apprentissage qui m’a plu. Ce rôle de consultant technique tel qu’on l’a à ekino, il n’existe pas ailleurs. C’est soit de la gestion de projet, soit de la partie technique; ici, on est vraiment sur ces deux aspects.

Étant un groupe international de 600 personnes réparties dans 5 pays, nous n’avons pas pu résister à cette épineuse question : Qu’en est-il des relations humaines ?

Michael: Lorsque je suis arrivé chez ekino, il y avait du monde, mais j’ai quand même trouvé quelque chose à taille humaine. Nous sommes environ 50 personnes à Bordeaux, donc c’est vraiment une agence de proximité où tout le monde se parle et se connaît. En plus de ça, je trouve que chez ekino, on est des experts et à chaque fois que j’ai eu une question complexe à poser, j’ai toujours trouvé quelqu’un qui répondait. 

  • « L’équipe est présente, elle est soudée et ça nous aide à avancer »

Même si notre consultant technique a très vite été inspiré par tous les aspects du métier, il nous a confié que parfois “Wow c’est chaud”. Au lieu de lui proposer à boire, on lui a plutôt demandé ce qui est important dans ces moments-là ? 

Michael :  C’est l’esprit d’équipe, l’entraide, la motivation. Ce sont des choses qui sont importantes pour les personnes et je trouve encore plus dans le rôle de consultant technique qui est pivot. Chez ekino, on retrouve tous ces aspects et ça fait du bien ! Sur l’ensemble des projets sur lesquels j’ai travaillé, les équipes avec qui j’ai bossé étaient top et certains sont devenus vraiment des amis.

Comme lors de notre rencontre avec Antoine (Quoi ? Tu ne sais pas encore qui est Antoine ?! OK, viens par ici), c’est le moment où on la joue un peu corporate mais surtout “Pas de tabou entre nous”

Michael : Il ne faut pas être des bisounours : il y a des projets qui sont parfois compliqués, mais souvent, l’équipe est présente; elle est soudée et ça nous aide à avancer. C’est ce qui donne aussi l’envie et la motivation de venir travailler et d’être présent pour ekino.

Bien hydratés des paroles ambitieuses et inspirantes de Michael, on espère que tu as maintenant soif de la vibe ekino. Michael et son équipe ont hâte de te rencontrer ! Passe nous voir à ekino Bordeaux, on aura toujours une bonne bouteille d’eau pour toi.

Comment auditer la viabilité technique et organisationnelle d’une future acquisition ?

Les facteurs organisationnels et technologiques ont également toute leur importance. Ce n’est un secret pour personne, les technologies digitales jouent un rôle de plus en plus grand dans les performances commerciales des entreprises. Par conséquent, leur adoption requiert bien souvent d’adopter un modèle organisationnel plus adapté au rythme du marché. Cet article vise à détailler […]

Lire la suite de Comment auditer la viabilité technique et organisationnelle d’une future acquisition ?